Download FAQ History |  | API Search Feedback

> ## XML and Related Specs: Digesting the Alphabet Soup

> Now that you have a basic understanding of XML, it makes sense to get a high-level overview of the various XML-related acronyms and what they mean. There is a lot of work going on around XML, so there is a lot to learn.

> The current APIs for accessing XML documents either serially or in random access mode are, respectively, SAX and DOM. The specifications for ensuring the validity of XML documents are DTD (the original mechanism, defined as part of the XML specification) and various Schema Standards proposals (newer mechanisms that use XML syntax to do the job of describing validation criteria).

> Other future standards that are nearing completion include the XSL standard--a mechanism for setting up translations of XML documents (for example to HTML or other XML) and for dictating how the document is rendered. The transformation part of that standard, XSLT (+XPATH), is completed and covered in this tutorial. Another effort nearing completion is the XML Link Language specification (XML Linking), which enables links between XML documents.

> Those are the major initiatives you will want to be familiar with. This section also surveys a number of other interesting proposals, including the HTML-lookalike standard, XHTML, and the meta-standard for describing the information an XML document contains, RDF. There are also standards efforts that extend XML's capabilities, such as XLink and XPointer.

> Finally, there are a number of interesting standards and standards-proposals that build on XML, including Synchronized Multimedia Integration Language (SMIL), Mathematical Markup Language (MathML), Scalable Vector Graphics (SVG), and DrawML, as well as a number of eCommerce standards.

> The remainder of this section gives you a more detailed description of these initiatives. To help keep things straight, it's divided into:

> - Basic Standards
> - Schema Standards
> - Linking and Presentation Standards
> - Knowledge Standards
> - Standards That Build on XML

> Skim the terms once, so you know what's here, and keep a copy of this document handy so you can refer to it whenever you see one of these terms in something you're reading. Pretty soon, you'll have them all committed to memory, and you'll be at least "conversant" with XML!

> ### Basic Standards

> These are the basic standards you need to be familiar with. They come up in pretty much any discussion of XML.

> #### SAX

> Simple API for XML

> This API was actually a product of collaboration on the XML-DEV mailing list, rather than a product of the W3C. It's included here because it has the same "final" characteristics as a W3C recommendation.

> You can also think of this standard as the "serial access" protocol for XML. This is the fast-to-execute mechanism you would use to read and write XML data in a server, for example. This is also called an event-driven protocol, because the technique is to register your handler with a SAX parser, after which the parser invokes your callback methods whenever it sees a new XML tag (or encounters an error, or wants to tell you anything else).

> #### DOM

> Document Object Model

> The Document Object Model protocol converts an XML document into a collection of objects in your program. You can then manipulate the object model in any way that makes sense. This mechanism is also known as the "random access" protocol, because you can visit any part of the data at any time. You can then modify the data, remove it, or insert new data.

> #### JDOM and dom4j

> While the Document Object Model (DOM) provides a lot of power for document-oriented processing, it doesn't provide much in the way of object-oriented simplification. Java developers who are processing more data-oriented structures--rather than books, articles, and other full-fledged documents--frequently find that object-oriented APIs like JDOM and dom4j are easier to use and more suited to their needs.

> Here are the important differences to understand when choosing between the two:

> - JDOM is somewhat cleaner, smaller API. Where "coding style" is an important consideration, JDOM is a good choice.
> - JDOM is a Java Community Process (JCP) initiative. When completed, it will be an endorsed standard.
> - dom4j is a smaller, faster implementation that has been in wide use for a number of years.
> - dom4j is a factory-based implementation. That makes it easier to modify for complex, special-purpose applications. At the time of this writing, JDOM does not yet use a factory to instantiate an instance of the parser (although the standard appears to be headed in that direction). So, with JDOM, you always get the original parser. (That's fine for the majority of applications, but may not be appropriate if your application has special needs.)

> For more information on JDOM, see `http://www.jdom.org/`.

> For more information on dom4j, see `http://dom4j.org/`.

> #### DTD

> Document Type Definition

> The DTD specification is actually part of the XML specification, rather than a separate entity. On the other hand, it is optional--you can write an XML document without it. And there are a number of Schema Standards proposals that offer more flexible alternatives. So it is treated here as though it were a separate specification.

> A DTD specifies the kinds of tags that can be included in your XML document, and the valid arrangements of those tags. You can use the DTD to make sure you don't create an invalid XML structure. You can also use it to make sure that the XML structure you are reading (or that got sent over the net) is indeed valid.

> Unfortunately, it is difficult to specify a DTD for a complex document in such a way that it prevents all invalid combinations and allows all the valid ones. So constructing a DTD is something of an art. The DTD can exist at the front of the document, as part of the prolog. It can also exist as a separate entity, or it can be split between the document prolog and one or more additional entities.

> However, while the DTD mechanism was the first method defined for specifying valid document structure, it was not the last. Several newer schema specifications have been devised. You'll learn about those momentarily.

> #### Namespaces

> The namespace standard lets you write an XML document that uses two or more sets of XML tags in modular fashion. Suppose for example that you created an XML-based parts list that uses XML descriptions of parts supplied by other manufacturers (online!). The "price" data supplied by the subcomponents would be amounts you want to total up, while the "price" data for the structure as a whole would be something you want to display. The namespace specification defines mechanisms for qualifying the names so as to eliminate ambiguity. That lets you write programs that use information from other sources and do the right things with it.

> The latest information on namespaces can be found at `http://www.w3.org/TR/REC-xml-names`.

> #### XSL

> Extensible Stylesheet Language

> The XML standard specifies how to identify data, not how to display it. HTML, on the other hand, told how things should be displayed without identifying what they were. The XSL standard has two parts, XSLT (the transformation standard, described next) and XSL-FO (the part that covers formatting objects, also known as flow objects). XSL-FO gives you the ability to define multiple areas on a page and then link them together. When a text stream is directed at the collection, it fills the first area and then "flows" into the second when the first area is filled. Such objects are used by newsletters, catalogs, and periodical publications.

> The latest W3C work on XSL is at `http://www.w3.org/TR/WD-xsl`.

> #### XSLT (+XPATH)

> Extensible Stylesheet Language for Transformations

> The XSLT transformation standard is essentially a translation mechanism that lets you specify what to convert an XML tag into so that it can be displayed--for example, in HTML. Different XSL formats can then be used to display the same data in different ways, for different uses. (The XPATH standard is an addressing mechanism that you use when constructing transformation instructions, in order to specify the parts of the XML structure you want to transform.)

> ### Schema Standards

> A DTD makes it possible to validate the structure of relatively simple XML documents, but that's as far as it goes.

> A DTD can't restrict the content of elements, and it can't specify complex relationships. For example, it is impossible to specify that a <heading> for a <book> must have both a <title> and an <author>, while a <heading> for a <chapter> only needs a <title>. In a DTD, you only get to specify the structure of the <heading> element one time. There is no context-sensitivity, because a DTD specification is not hierarchical.

> For example, for a mailing address that contains several "parsed character data" (PCDATA) elements, the DTD might look something like this:

>     <!ELEMENT mailAddress (name, address, zipcode)>
>     <!ELEMENT name (#PCDATA)>
>     <!ELEMENT address (#PCDATA)>
>     <!ELEMENT zipcode (#PCDATA)>

> As you can see, the specifications are linear. So if you need another "name" element in the DTD, you need a different identifier for it. You could not simply call it "name" without conflicting with the <name> element defined for use in a <mailAddress>.

> Another problem with the non hierarchical nature of DTD specifications is that it is not clear what comments are meant to explain. A comment at the top like might be intended to apply to the whole structure, or it might be intended only for the first item. Finally, DTDs do not allow you to formally specify field-validation criteria, such as the 5-digit (or 5 and 4) limitation for the `zipcode` field.

> Finally, a DTD uses syntax which is substantially different from XML, so it can't be processed with a standard XML parser. That means you can't read a DTD into a DOM, for example, modify it, and then write it back out again.

> To remedy these shortcomings, a number of proposals have been made for a more database-like, hierarchical "schema" that specifies validation criteria. The major proposals are shown below.

> #### XML Schema

> A large, complex standard that has two parts. One part specifies structure relationships. (This is the largest and most complex part.) The other part specifies mechanisms for validating the content of XML elements by specifying a (potentially very sophisticated) datatype for each element. The good news is that XML Schema for Structures lets you specify virtually any relationship you can conceive. The bad news is that it is very difficult to implement, and it's hard to learn. Most of the alternatives provide for simpler structure definitions, while incorporating XML Schema's datatyping mechanisms.

> For more information on XML Schema, see the W3C specs XML Schema (Structures) and XML Schema (Datatypes), as well as other information accessible at `http://www.w3c.org/XML/Schema`.

> #### RELAX NG

> REgular LAnguage description for XML (Next Generation)

> Simpler than XML Structure Schema, RELAX NG is an emerging standard under the auspices of OASIS (Organization for the Advancement of Structured Information Systems). It may become an ISO standard in the near future, as well.

> RELAX NG uses regular expression patterns to express constraints on structure relationships, and it is uses XML Schema datatyping mechanisms to express content constraints. This standard also uses XML syntax, and it includes a DTD to RELAX converter. (It's "next generation" because it's a newer version of the RELAX schema mechanism that integrates TREX.)

> For more information on RELAX NG, see `http://www.oasis-open.org/committees/relax-ng/`

> #### TREX

> Tree Regular Expressions for XML

> A means of expressing validation criteria by describing a pattern for the structure and content of an XML document. Now part of the RELAX NG specification.

> For more information on TREX, see `http://www.thaiopensource.com/trex/`.

> #### SOX

> Schema for Object-oriented XML

> SOX is a schema proposal that includes extensible data types, namespaces, and embedded documentation.

> For more information on SOX, see `http://www.w3.org/TR/NOTE-SOX`.

> #### Schematron

> Schema for Object-oriented XML

> An assertion-based schema mechanism that allows for sophisticated validation.

> For more information on the Schematron validation mechanism, see `http://www.ascc.net/xml/resource/schematron/schematron.html`.

> ### Linking and Presentation Standards

> Arguably the two greatest benefits provided by HTML were the ability to link between documents, and the ability to create simple formatted documents (and, eventually, very complex formatted documents). The following standards aim at preserving the benefits of HTML in the XML arena, and to adding additional functionality, as well.

> #### XML Linking

> These specifications provide a variety of powerful linking mechanisms, and are sure to have a big impact on how XML documents are used.

> XLink

> The XLink protocol is a specification for handling links between XML documents. This specification allows for some pretty sophisticated linking, including two-way links, links to multiple documents, "expanding" links that insert the linked information into your document rather than replacing your document with a new page, links between two documents that are created in a third, independent document, and indirect links (so you can point to an "address book" rather than directly to the target document--updating the address book then automatically changes any links that use it).

> XML Base

> This standard defines an attribute for XML documents that defines a "base" address, that is used when evaluating a relative address specified in the document. (So, for example, a simple file name would be found in the base-address directory.)

> XPointer

> In general, the XLink specification targets a document or document-segment using its ID. The XPointer specification defines mechanisms for "addressing into the internal structures of XML documents", without requiring the author of the document to have defined an ID for that segment. To quote the spec, it provides for "reference to elements, character strings, and other parts of XML documents, whether or not they bear an explicit ID attribute".

> For more information on the XML Linking standards, see `http://www.w3.org/XML/Linking`.

> #### XHTML

> The XHTML specification is a way of making XML documents that look and act like HTML documents. Since an XML document can contain any tags you care to define, why not define a set of tags that look like HTML? That's the thinking behind the XHTML specification, at any rate. The result of this specification is a document that can be displayed in browsers and also treated as XML data. The data may not be quite as identifiable as "pure" XML, but it will be a heck of a lot easier to manipulate than standard HTML, because XML specifies a good deal more regularity and consistency.

> For example, every tag in a well-formed XML document must either have an end-tag associated with it or it must end in `/>`. So you might see `<p>...</p>`, or you might see `<p/>`, but you will never see `<p>` standing by itself. The upshot of that requirement is that you never have to program for the weird kinds of cases you see in HTML where, for example, a `<dt>` tag might be terminated by `</DT>`, by another `<DT>`, by `<dd>`, or by `</dl>`. That makes it a lot easier to write code!

> The XHTML specification is a reformulation of HTML 4.0 into XML. The latest information is at `http://www.w3.org/TR/xhtml1`.

> ### Knowledge Standards

> When you start looking down the road five or six years, and visualize how the information on the Web will begin to turn into one huge knowledge base (the "semantic Web"). For the latest on the semantic Web, visit `http://www.w3.org/2001/sw/`.

> In the meantime, here are the fundamental standards you'll want to know about:

> #### RDF

> Resource Description Framework

> RDF is a standard for defining meta data--information that describes what a particular data item is, and specifies how it can be used. Used in conjunction with the XHTML specification, for example, or with HTML pages, RDF could be used to describe the content of the pages. For example, if your browser stored your ID information as `FIRSTNAME`, `LASTNAME`, and `EMAIL`, an RDF description could make it possible to transfer data to an application that wanted `NAME` and `EMAILADDRESS`. Just think: One day you may not need to type your name and address at every Web site you visit!

> For the latest information on RDF, see `http://www.w3.org/TR/REC-rdf-syntax`.

> #### RDF Schema

> RDF Schema allows the specification of consistency rules and additional information that describe how the statements in a Resource Description Framework (RDF) should be interpreted.

> For more information on the RDF Schema recommendation, see `http://www.w3.org/TR/rdf-schema`.

> #### XTM

> XML Topic Maps

> In many ways a simpler, more readily usable knowledge-representation than RDF, the topic maps standard is one worth watching. So far, RDF is the W3C standard for knowledge representation, but topic maps could possibly become the "developer's choice" among knowledge representation standards.

> For more information on XML Topic Maps, `http://www.topicmaps.org/xtm/index.html`. For information on topic maps and the Web, see `http://www.topicmaps.org/`.

> ### Standards That Build on XML

> The following standards and proposals build on XML. Since XML is basically a language-definition tool, these specifications use it to define standardized languages for specialized purposes.

> #### Extended Document Standards

> These standards define mechanisms for producing extremely complex documents--books, journals, magazines, and the like--using XML.

> ##### SMIL

> Synchronized Multimedia Integration Language

> SMIL is a W3C recommendation that covers audio, video, and animations. It also addresses the difficult issue of synchronizing the playback of such elements.

> For more information on SMIL, see `http://www.w3.org/TR/REC-smil`.

> ##### MathML

> Mathematical Markup Language

> MathML is a W3C recommendation that deals with the representation of mathematical formulas.

> For more information on MathML, see `http://www.w3.org/TR/REC-MathML`.

> ##### SVG

> Scalable Vector Graphics

> SVG is a W3C working draft that covers the representation of vector graphic images. (Vector graphic images that are built from commands that say things like "draw a line (square, circle) from point xi to point m,n" rather than encoding the image as a series of bits. Such images are more easily scalable, although they typically require more processing time to render.)

> For more information on SVG, see `http://www.w3.org/TR/WD-SVG`.

> ##### DrawML

> Drawing Meta Language

> DrawML is a W3C note that covers 2D images for technical illustrations. It also addresses the problem of updating and refining such images.

> For more information on DrawML, see `http://www.w3.org/TR/NOTE-drawml`.

> #### eCommerce Standards

> These standards are aimed at using XML in the world of business-to-business (B2B) and business-to-consumer (B2C) commerce.

> ##### ICE

> Information and Content Exchange

> ICE is a protocol for use by content syndicators and their subscribers. It focuses on "automating content exchange and reuse, both in traditional publishing contexts and in business-to-business relationships".

> For more information on ICE, see `http://www.w3.org/TR/NOTE-ice`.

> ##### ebXML

> Electronic Business with XML

> This standard aims at creating a modular electronic business framework using XML. It is the product of a joint initiative by the United Nations (UN/CEFACT) and the Organization for the Advancement of Structured Information Systems (OASIS).

> For more information on ebXML, see `http://www.ebxml.org/`.

> ##### cxml

> Commerce XML

> cxml is a RosettaNet (`www.rosettanet.org`) standard for setting up interactive online catalogs for different buyers, where the pricing and product offerings are company specific. Includes mechanisms to handle purchase orders, change orders, status updates, and shipping notifications.

> For more information on cxml, see `http://www.cxml.org/`

> ##### CBL

> Common Business Library

> CBL is a library of element and attribute definitions maintained by CommerceNet (`www.commerce.net`).

> For more information on CBL and a variety of other initiatives that work together to enable eCommerce applications, see `http://www.commerce.net/projects/currentprojects/eco/wg/eCo_Framework_Specifications.html`.

> ##### UBL

> Universal Business Language

> An OASIS initiative aimed at compiling a standard library of XML business documents (purchase orders, invoices, etc.) that are defined with XML Schema definitions.

> For more information on UBL, see `http://www.oasis-open.org/committees/ubl`.

> ### Summary

> XML is becoming a widely-adopted standard that is being used in a dizzying variety of application areas.

Download FAQ History |  | API Search Feedback

All of the material in The Java(TM) Web Services Tutorial is copyright-protected and may not be published in other works without express written permission from Sun Microsystems.