- What is a Markup Language
- What is XML?
- XML versus HTML?
- History of XML
- Advantages of XML
- Disadvantages of XML
And what's more, since everyone followed the same standard of marking up, you could easily pick up a used textbook and get a good idea just from reading the highlighted sections what were core points of the book.
So, It is possible to classify markup as one of the three types: stylistic, structural or semantic.
Stylistic Markup
This indicates how the document is to be presented. In HTML, stylistic markup could be <FONT>, <I>, <B> and <U> tags.Structural Markup
This informs us of how the document is to be structured. In HTML, structural markup could be <P> and <DIV> tags to indicate a paragraph and container section respectively.Semantic Markup
This tells us something about the content of the data. In HTML, semantic markup could be <TITLE> tag.By now, you should have a clear idea about what is a mark up language - right! So, let's move on!!! ]]>
However, XML is far morepowerful than HTML. The secret is because of the X. XML is "eXtensible". Specifically, rather than providing a set of pre-defined tags, as in the case of HTML, XML specifies the standards with which you can define your own markup languages with their own sets of tags. XML is a meta-markup language which allows you to define an infinite number of markup languages based upon the standards defined by XML.
In HTML, web authors often use tables to present their product information such as:
product.html
| <TABLE BORDER=1> | ||
| <TR> | ||
| <TH>Product ID</TH> | ||
| <TH>Description</TH> | ||
| <TH>Price</TH> | ||
| </TR> | ||
| <TR> | ||
| <TD>656565</TD> | ||
| <TD>Pentium III</TD> | ||
| <TD>$1999.99>/TD> | ||
| </TR> | ||
| </TABLE> | ||
Your HTML browser renders the example above like so:
| Product ID | Description | Price |
|---|---|---|
| 656565 | Pentium III | $1999.99 |
XML uses markup tags as well, but unlike HTML, XML tags describe the content, rather than the presentation of that content. So, in the example above instead of using <TABLE>, we would define our own tag called <product>. Thus, the same example above could be coded in XML as:
| product.xml | |
| <product> | |
| <id>656565</id> | |
| <description>Pentium III</description> | |
| <price>$1999.99</price> | |
| </product> | |
Ironically, by avoiding formatting tags in the data, but marking the meaning of the data itself with <product>, we actually make it easier for a client to search various individual servers for a product and receive a product list tailored to the preferences of the user.
]]>
XML is about data
HTML is about displaying information, whereas XML is about describing information (as shown in the example above).
XML is extensible
XML allows the author to define his own tags and his own document structure. Whereas, in HTML, the HTML authors must use a pre-defined tags and structure that HTML has provided.
XML is a complement to HTML
]]>It is important to understand that XML is not a replacement for HTML. In the future development of the Web, it is most likely that XML will be used to structure and describe the Web data, while HTML will be used to format and display the same data.
SGML, the international standard for marking up data, has been used since the 80s. SGML is an extremely powerful and extensible tool for semantic markup which is particularly useful for cataloging and indexing data. However, SGML is pretty darn complex, especially for the everyday uses of the web. Not only that, SGML is pretty expensive as well. Thus, the commercial browsers made it pretty clear that they did not intend to ever support SGML.
HTML on the other hand was free, simple and widely supported. HTML was originally designed at CERN around 1990 to provide a very simple version of SGML which could be used by regular people. As everyone knows, HTML spreads like wildfire. Unfortunately, HTML has serious defects as follow:
- The GUI is embedded in the data which make it hard to modify the content.
- Searching for information in the data is tough.
- The data is tied to the logic and language of HTML.
So in 1996, discussions began which focused on how to define a markup language with the power and extensibility of SGML but with the simplicity of HTML. The World Wide Web Consortium (W3C) decided to sponsor a group of SGML gurus including Jon Bosak from Sun.
Essentially, Bosak and his team did to SGML what the Java team had done to C++. All of the non-essential, unused, cryptic parts of SGML were sliced away. What remained was a clean, mean marking up machine: that is XML.
The specification of XML (written mostly by Tim Bray and C.M. Sperberg-McQueen) was only 26 pages as opposed to the 500+ pages of the SGML specification! Nevertheless, all the useful things which could be done by SGML, could also be done with XML.
Over the next few years, XML evolved, drawing from the work of its sponsors and the work of developers solving similar problems such as Peter Murray-Rust who had been working on CML (Chemical Markup Language) and the consortium of folks working on MML or MathML (Mathematic Markup Language). By mid 1997 the XLL (eXtensible Linking Language) project was underway and by the summer of 1997, Microsoft had launched the CDF (Channel Definition Format) as one of the first real-world applications of XML.
Finally, in 1998, the W3C approved Version 1.0 of the XML specification and a new language was born.
]]>Of course, not only are you free to develop at your own pace, but you are also free to develop tools that meet your needs exactly.
By defining your own tags, you create the markup language in terms of your specific problem set! Rather than relying on a generic set of tags which suits everyone's needs adequately, XML allows every person or organization to build their own tag library which suits their needs perfectly.
XML allows each specific industry to develop its own tag sets to meet its unique needs without forcing everyone's browser to incorporate the functionality of zillions of tag sets, and without forcing the developers to settle for a generic tag set that is too generic to be useful.
The real power of XML comes from the fact that with XML, not only can you define your own set of tags, but the rules specified by those tags need not be limited to formatting rules. XML allows you to define all sorts of tags with all sorts of rules, such as tags representing business rules or tags representing data description or data relationships.
- With XML, the GUI is extracted. Thus, changes to display do not require futzing with the data. Instead, a separate style sheet will specify a table display ora list display.
- Searching the data is easy and efficient. Search engines can simply parse the description-bearing tags rather than muddling in the data. Tags provide the search engines with the intelligence they lack.
- Complex relationships like trees and inheritance can be communicated.
- The code is much more legible to a person coming into the environment with no prior knowledge.
The most common tactic used now is to write parsing routines in DHTML or Java, or Server-Side PERL to parse through an XML document, apply the formatting rules specified by the style sheet, and convert it all to HTML.
]]>HTML pages are used to display data. Data is often stored inside HTML pages. With XML this data can now be stored in a separate XML file. This way you can concentrate on using HTML for formatting and display, and be sure that changes in the underlying data will not force changes to any of your HTML code.
XML can be used to store data inside HTML documents.
XML data can also be stored inside HTML pages as Data Islands. You can still concentrate on using HTML for formatting and displaying the data.
XML can be used as a format to exchange information.
In the real world, computer systems and databases contain data in incompatible formats. One of the most time consuming challenges for developers has been to exchange data between such systems over the Internet. Converting the data to XML can greatly reduce this complexity and create data that can be read by different types of applications.
XML can be used to store data in files or in the databases.
]]>Applications can be written to store and retrieve information from the store, and generic applications can be used to display the data.
| Line-by-line code | Explanation |
| <?xml version="1.0"?> | The XML declaration should always be included. It defines the XML version of the document. In this case, the document conforms to the 1.0 specification of XML. |
| <note> | Defines the first element (the root element) of the document. |
| <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!!!</body> |
Defines 4 elements of the root (to, from, heading and body). |
| </note> | The last line defines the end of the root element. |
In HTML some elements do not have to have a closing tag. The following code is legal in HTML:
| <p>This is a paragraph | |
| <p>This is another paragraph |
In XML all elements must have a closing tag like this:
| <p>This is a paragraph</p> | |
| <p>This is another paragraph</p> |
2. XML tags are case sensitive
XML tags are case sensitive. Opening and closing tags must therefore be written with the same case.
 |
<Message>This is incorrect</message> |
| <message>This is correct</message> |
Important: Tags should begin with either a letter, an underscore (_) or a colon (:) followed by some combination of letters, numbers, periods (.), colons, underscores, or hyphens (-) but no white space, with the exception that no tags should begin with any form of "xml". It is also a good idea to not use colons as the first character in a tag name even if it is legal. Using a colon first could be confusing. Here are some legal and illegal tags examples:
| Legal tags | Illegal tags |
| <first-name> | <first - name> |
| <last.name> | <last . name> |
| <namexml> | <xmlname> |
3. All XML elements must be properly nested
In HTML some elements can be improperly nested within each other like this:
| <b><i>This text is bold and italic</b></i> |
In XML, all elements must be properly nested within each other like this:
| <b><i>This text is bold and italic</i></b> |
4. All XML documents must have a root tag
All XML documents must contain a single tag pair to define the root element. All other elements must be nested within the root element. All elements can have sub (children) elements. Sub elements must be in pairs and correctly nested within their parent element. eg.
| <root> | ||
| <child> | ||
| <subchild> | ||
| </subchild> | ||
| </child> | ||
| </root> | ||
5. Attribute values must always be quoted
XML elements can have attributes in name/value pairs just like in HTML. In XML the attribute value must always be quoted. eg.
| Correct | Incorrect |
| <?xml version="1.0"?> | <?xml version="1.0"?> |
| <note date="25/06/00"> | <note date=25/06/00> |
Avoid using attributes?
Attributes are handy in HTML. But in XML you should try to avoid them (you could easily substitute attributes by elements - I will show you later so you could get the idea!!!). Why? Below are some of the problems using attributes.
Let me clear up your doubt by looking at the following example:
An XML example
| <?xml version="1.0"?> | |
| <note> | |
| <date>12/11/00</date> | |
| <to>Tove</to> | |
| <from>Jani</from>> | |
| <subject>Reminder</subject> | |
| <body>Don't forget me this weekend</body> | |
| </note> | |
If you look at the element <date> above, how do you interpret it??? Is this 12. of November or 11. of December???
Now, let see how you can expand the <date> element:
| <?xml version="1.0"?> | ||
| <note> | ||
| <date> | ||
| <date>12</date> | ||
| <month>11</month> | ||
| <year>99</year> | ||
| </date> | ||
| <to>Tove</to> | ||
| <from>Jani</from> | ||
| <heading>Reminder</heading> | ||
| <body>Don't forget me this weekend</body> | ||
| </note> | ||
Got the idea???
]]>- The document must contain one or more elements.
- It must contain a uniquely name element, no part of which appears in the content of any other element, known as the root element.
- All other elements within the root element must be correctly nested.
So, according to these rules, the following are examples of well formed documents:
example1.xml
<empty_tag></empty_tag>
example2.xml
<?xml version="1.0"?>
<class>Mammalia</class>example3.xml
<root>
<class>Mammalia</class>
</root>example4.xml
<empty_tag/>
Note: example1.xml and example4.xml are the same.
The following is example of not well formed documents:
bad_example.xml
<bad_parent>
<naughty_child>Some text info
</bad_parent>
</naughty_child>
Explanation: If you look carefully, you can see that the element <naughty_child> overshoots the end of the <bad_parent> element, which should encapsulate the <naughty_child> element completely (According to rule 3 above).
]]>As opposed to physical structure, XML documents have a logical structure as well. Logically, documents are composed of declarations, elements, comments, character references and processing instructions, all of which are indicated in the document by explicit markup.
]]>Data is typically "character data" (i.e. anything within the boundaries of valid Unicode such as letters, numbers, punctuation and so on) but can also be binary data as well.
Markup includes tags, comments, processing instructions, DTDs and references and so forth.
For example: <name>John Smith</name>
Explanation: <name>and </name> tags comprise the markup and "John Smith" comprises the character data.
]]>Essentially, the XML declaration is a processing instruction that notifies the processing agent (browser)
that the following document has been marked up as an XML document. It will look something like the following:
| <?xml version="1.0"?> |
OR having a white space in between as shown below.
| <?xml version = "1.0" ?> |
We will talk more about the gory details of processing instructions later, for now...we concentrate on explaining how the XML declaration works okie!
All processing instructions, including the XML declaration should have the following syntax:
| <?name .... ?> |
It must begin with <? and end with ?>. Following the initial <?, you will find the name of the processing instruction, which in this case is "xml".
The XML processing instruction, requires that you specify a version attribute and allows you to specify optional standalone and encoding attributes.
In its full regalia, the XML declaration might look like the following:
<?xml version="1.0" standalone="yes" encoding="UTF-8"?>
The Version Attribute
As we have mentioned before, if you do decide to use the optional XML declaration, you must define the version attribute. As of this writing, the current version of XML is 1.0.
If you include the optional attributes, version must be specified first.
The STANDALONE Attribute
The standalone attribute specifies whether the document has any markup declarations that are defined in a separate document. Thus, if standalone is set to "yes", the document is effectively self-contained and there are no extra markup declarations in external DTD's. However, setting the standalone to "no" leaves the issue open. Remember that the document may or may not access external DTD's.
For examples:
| standalone_yes.xml | |
| <?xml version="1.0" standalone="yes" encoding="UTF-8"?> | |
| <book> | |
| <title>Professional XML Design and Implementation</title> | |
| <author>Paul Spencer</author> | |
| <publisher>Wrox</publisher> | |
| <price>$83.95</price> | |
| </book> | |
standalone_no.xml | |
| <?xml version="1.0" standalone="no" encoding="UTF-8"?> | |
| <!DOCTYPE book SYSTEM "book.dtd"> | |
| <book> | |
| <title>Professional XML Design and Implementation</title> | |
| <author>Paul Spencer</author> | |
| <publisher>Wrox</publisher> | |
| <price>$83.95</price> | |
| </book> | |
Note: As you can see, if standalone="no" which means the XML document should use an external DTD. In this case, use book.dtd file to check for validating document.
The ENCODING Attribute
All XML parsers must support 8-bit and 16-bit Unicode encoding (UTF-8 and UTF-16 respectively) corresponding to ASCII. However, XML parsers may support a larger set.
]]>Elements are the basic unit of XML content. Syntactically, an element consists of a start tag, and an end tag, and everything in between. For example, consider the following element:
<name>John Smith</name>
Tags
Tags are used to markup elements. A starting tag like <name> mark up the beginning of an element, and an ending tag like </name> mark up the end of an element.
Attributes
Attributes provide extra information about elements.
Let say, in our xml document - we have the following line:
<img src="bird.gif"/>
| A line of code above | Explanation |
| <img src="bird.gif"/> | img is the element name |
Attribute always come in name/value pairs and attribute value must be quoted.
Since
the "<" and ">" are the reserved characters
for the start and end of a tag - respectively. Thus character data may
be any legal (Unicode) character except the "<" and ">"
can not be used. The following example is incorrect.
<comparison>12 < 13</comparison>
Alternative solution:
<comparison>12 < 13</comparison>
Here is the question you might ask yourself. How am I supposed to know which characters that
legal or illegal to use? Well, not too worries - XML provides a couple
of useful entity references that you can use:
| Character | Entity Reference | Meaning |
|---|---|---|
| > | > | Greater than |
| < | < | Less than |
| & | & | Ampersand |
| " | " | Double quote |
| ' | ' | Apostrophe (Single quote) |
Obviously, the < entity reference is useful for character data. The other entity references can be used within markup in cases in which there could be confusion such as:
<statement value="She said, "Don't go there!"">
Which should be written as:
<statement value="She said, "Don't go there!"">
By and large, tags make up the majority of XML markup. A tag is pretty much anything between a < sign and a > sign that is not inside a comment, or a CDATA section (Read on next section, please!).
]]>As we have said already, it is a pretty good rule of thumb to consider anything outside of tags to be character data and anything inside of tags to be considered markup. But alas, how am I going to show the ">" or any other reserved characters on the browser? and worse still, if I decide to have lots of reserved characters to show up the browser, do I have to key in all the funny entity reference symbols???
Of course not, XML has provided you a wonderful feature that you can use. That is the special case of CDATA blocks, it is provided as a convenience measure when you want to include large blocks of special characters as character data. By including CDATA block, you actually tell the XML processor (browser) to treat everything inside CDATA section just like any others ordinary character data. (that means all tags and entity references are ignored by an XML processor)
Let's say you want to display XML document on the browser, you can construct your XML document as follow:
| <example> | |
| <document> | |
| <name>Trina Thach</name> | |
| <email>trina@technomusic.org</email> | |
| </document> | |
| </example> | |
As you can see, you would be forced to use entity references for all the tags. What's a mess!
Thus, to avoid the inconvenience of translating all special characters, you can use a CDATA block to specify that all character data should be considered character data whether or not it looks like a tag or entity reference.
Now, allow me to show you how easy it is by applying CDATA block within XML document:
| <example> | |||
| <![CDATA[ | |||
| <document> | |||
| <name>Trina Thach</name> | |||
| <email>trina@technomusic.org</email> | |||
| </document> | |||
| ]]> | |||
| </example> | |||
See how readable and legible it is???
As you might have guessed, the character string ]]> is not allowed within a CDATA block as it would signal the end of the CDATA block.
In HTML, you specified comments using the <!-- and --> syntax. Well, I have some good news. In XML, comments are done in just the same way! So the following would be a valid XML comment:
<!-- Begin the Names -->
<name>Jim Nelson</name>
<name>Sam Sanger</name>
<name>Les Moore</name>
<!-- End the names -->
When using comments in your XML documents, however, you should keep in mind a couple of rules.
Should
not have "-" or "--" within the text of your comment as it might be confusing to the XML processor.
Never
ever place a comment within a tag. Thus, the following code would be poorly-formed XML
<name <!--The name --> >Peter Williams </name>
Likewise,
never place a comment inside of an entity declaration and never place
a comment before the XML declaration that must always be the first line in any XML document.
Comments can be used to comment out tag sets. Thus, in the following case, all the names will be ignored except for Barbara Tropp.
<!-- don't show these
<name>David Drinkwater</name>
<name>Joe Smith</name>
<name>John Paul Young</name>
-->
<name>Barbara Tropp</name>
However, if you do comment out blocks of tags, make sure that the remaining XML is well-formed.
]]>So here we are.
| A processing instruction is a bit of information meant for the application using the XML document. That is, they are not really of interest to the XML parser. Instead, the instructions are passed intact straight to the application using the parser. |
The application can then pass this on to another application or interpret it itself.
All processing instructions follow the generic format of:
| <?name_of_app_instruction_is_for_instructions?> |
As you might imagine, you cannot use any combination of "xml" as the name_of_application_instruction_is_for since "xml" is reserved. However, you might have something like:
]]><?JAVA_OBJECT JAR_FILE= "/java/myjar.jar"?>
Entities are variables used to define common text that allow you to refer to large sections of text without having to type them out every time you want to use them. Suppose you have your letterhead saved as an entity in a shared file. Then, every time you write a letter in XML, you might say something like:
<letter>
&letterhead;
<to>Bob Frog</to>
<body>
blah blah blah
</body>
<from>Kevin Kelly</from>
</letter>
Notice that the letterhead might expand out to:
My Company
13 Fairy Street
Suite 156
Bankstown, Sydney 2196.
However, instead of typing that out in every letter, you just use:
&letterhead;
There are two types of entities, general and parameter entities and each entity has two parts, the declaration and the entity reference.
]]>Note: You can also specify an entity that has text defined externally to the document by using the SYSTEM keyword such as:
<!ENTITY license_agreement SYSTEM "http://www.mydomain.com/license.xml">
In this case, the XML processor will replace the entity reference with the contents of the document specified.
]]><!ENTITY % NAME "text that you want to be represented by the entity">
]]>|
<?xml version="1.0"?> <!DOCTYPE my_document [ ...here is where you declare your entities.... ]> <my_document> ...here is the body of your document.... </my_ocument> |
Thus, you might have something like the following:
<?xml version="1.0"?>
<!DOCTYPE clients [
<!ENTITY nineth_floor_address "2345 Broadway St Floor 9">
<!ENTITY eighth_floor_address "2345 Broadway St Floor 8">
<!ENTITY seventh_floor_address "2345 Broadway St Floor 7">
]>
<clients>
<client>
<name>Willy Smith</name>
<address>&nintha_floor_address;</address>
<phone>x345</phone>
</client>
<client>
<name>Jet Li</name>
<address>&ninth_floor_address;</address>
<phone>x111</phone>
</client>
<client>
<name>John Drayton</name>
<address>&ninth_floor_ddress;</address>
<phone>x346</phone>
</client>
<client>
<name>David Drinkwater</name>
<address>&seventh_floor_address;</address>
<phone>x289</phone>
</client>
<client>
<name>Kristin Kelly</name>
<address>&eighth_floor_address;</address>
<phone>x945</phone>
</client>
</clients>
Consider how much easier changing office addresses is when you use entities!!!
]]>Entity Reference - Referring to General Entities
Well we have pretty much let the cat out of the bag already. We have shown several examples of entity references above. Let's us take even a closer look of what we have covered before! oh! I am trying to make it short and simple, okay!
So what is entity reference? Entity References refer to the key that unlocks an entity which has been
declared in an Entity Declaration. Entity References follow the simple syntax of:
| &entity_name; |
such as
&letterhead;
Entities must be declared in an XML document before they are referenced.
Should
not have any whitespace embedded in an entity reference. In other words,
& letterhead; or &letterhead ; will cause errors.
Though
entities may refer to other entities, they may not be self-referential
either directly or indirectly. So the following declarations are not allowed.
| Example1 | Explanation |
| <!ENTITY net "Talk about the &net;"> | Entity contains references to itself (direct) |
| Example2 | Explanation |
| <!ENTITY
one "refer to &two;"> <!ENTITY two "refer to &one;"> |
Entities contains reference to themselves (indirect) |
But entities can refer to other entities as long as there is no direct or indirect self-reference of the type above. So we can have:
<!ENTITY where
"the mat.">
<!ENTITY didwhat "sat on &where;">
<!ENTITY who "The cat &didwhat;">
If we then used the reference &who; within the content of an element, the entity references would be expanded by the parser, and the replacement text formed to give "The cat sat on the mat."
References to entities may not appear in the DOCTYPE declaration.
The text that the entity references must be well-formed XML.
Entity Reference - Referring to Parameter Entities
As you might expect parameter entity references work much like general entity references. In this case, we use a "%" sign instead of a "&".
| %parameter_entity_name; |
Before we leave the subject, I would only mention that you could also use entity references within tag attributes. For example, consider the following:
<invoice client="&IBM;" product="&PRODUCT_ID_8762;" quantity="5">
You may not reference an external entity from within element attributes.
The referenced text may not contain the < character because it would cause a well-formed error in the element when replaced.
]]>