In just a few years, XML's importance to Java developers has grown by leaps and bounds, especially with Web services on the scene. XML, however, is an evolving technology with numerous subtechnologies emerging to solve common problems. With that in mind, how can a Java developer hope to keep up? This glossary of important XML acronyms will help you dip your feet into the XML pond. I assume some XML knowledge, such as that you understand attributes and elements and know how an XML document looks. To further aid your knowledge, for each technology introduced here, I've included a list of related Websites in Resources.
As for structure, I've split the acronyms into four topical sections:
- Develop with XML
- XML building blocks
- Communicate with XML
- Display XML
Within each section, rather than a mere alphabetical list, I've listed the terms in order of importance or relevance to other terms within the section. For quick links to specific terms, use the following alphabetical list:
- XML Base
Develop with XML
By "Develop with XML," I mean writing Java code. You'd use each of the technologies below, all used by typing
import ...;, to read or write XML documents. I've started with the most important, although certainly not the most interesting or even useful.
DOM (Document Object Model) is the standard in-memory XML representation. DOM proves flexible in that you can access any document bits whenever you want, but it can be memory hungry, so developers commonly use it to build client applications where memory is not an issue. DOM suffers from being old, language-neutral (so it is a lowest common denominator solution), and works with ill-formed HTML documents—all of which add up to a fairly unfriendly API. Many developers upgrade to JDOM or DOM4J.
SAX (Simple API for XML) differs from DOM in that it is event-driven: the document flashes before your eyes while the parser notifies you of elements and attributes. You pick out the bits you want as it goes by. SAX is lightweight and simple, but working out your location in a document can be challenging. Developers generally use SAX in server applications where memory can be tight.
JAXP (Java API for XML Parsing) is not really a technology separate from DOM or SAX, but simply an extension to both that makes them easier to use in Java. Both DOM and SAX are language-neutral, so neither answers questions like, "How do we create a parser." JAXP answers the creation question and is a standard API for XSLT (Extensible Stylesheet Language Transformations) (see below).
To those struggling with DOM, JDOM will seem like a breath of fresh air. JDOM fixes some of DOM's more arcane areas. For example, unlike with DOM, in JDOM elements and attributes are objects, so you can call
new Element("name"); and so on. JDOM uses Java collections and helps you write files, another area where DOM falls short. JDOM is being standardized under JSR 102 (Java Specification Request), which indicates Sun Microsystes' conviction that JDOM is a good solution.
JDOM's greatest strengths include its ease of use and specification compliance, but some developers criticize its performance. At the time of this writing, JDOM has not yet officially reached version 1.0; however, it is already stable and fairly bug-free, so don't let the version number put you off.
If you are considering JDOM, also consider DOM4J.
Because DOM4J fixes the same DOM problems as JDOM, they have similar APIs. In fact, DOM4J was originally a fork from JDOM. They differ most in that DOM4J, like DOM, uses interfaces in some places where JDOM uses objects; consequently, in DOM4J, you need a factory to create elements, attributes, and so on. While that makes DOM4J slightly harder to use, it does make DOM4J more flexible, since there can be several
Sun used DOM4J in the JAXM (Java APIs for XML Messaging) reference implementation, so Sun clearly sees DOM4J as a viable and sensible solution. As a DOM4J advantage compared to JDOM, DOM4J includes Jaxen, letting you use Xpath expressions to select nodes from the tree. While Jaxen also works with JDOM, the two are not well integrated.
JAXB (Java API for XML Binding) offers a fresh method to parse XML documents. So fresh that the ink has yet to dry, so to speak. JAXB, not due for release until the end of 2002, is an in-memory model like the DOM variants, but the similarity with DOM ends there. With JAXB, you compile your DTD (document type definition) (or soon XML Schema) into Java classes. You sometimes will write instructions to the compiler to help it create exactly the Java classes you want or you can let it create defaults.
From that point on, the only APIs you need are your newly created Java classes. The current JAXB early access release creates Java classes with methods called
unmarshal(), which load and save to and from disk; from then on you use getters and setters just like in any other JavaBean.
JAXB represents a promising way to ease XML editing. It's a technology worth watching.
XML building blocks
XML building block technologies represent the foundation upon which the rest of the XML world is built. An understanding of many of these key technologies proves vital to employing the technologies found in this glossary's other sections.
Namespaces let you mix tags from different sources without confusing their origin. Each element in a namespace acquires two extra bits of information.
First, and most importantly, is a unique identifier, generally resembling a URL, that distinguishes elements from different sources. While unique identifiers resemble URLs, you're not guaranteed a response if you type an identifier into a Web browser. For example, XSL (Extensible Stylesheet Language) uses
"http://www.w3.org/1999/XSL/Transform" as its unique identifier, which every element using the specified namespace includes.
However, if you had to type that whole string each time you used an element, things would quickly become unreadable. In response, namespaces' second extra bit of information is a shortcut. For XSL, developers generally use the string
xsl, but any string would do.
You must associate the shortcut with the unique identifier, accomplished by placing an
xmlns attribute on a parent element. For example:
The above code announces that, for this element, and all its children, the prefix
xsl refers to the namespace
http://www.w3.org/1999/XSL/Transform. Whenever you use an element from this namespace, you should prefix it with the shortcut string:
That way a processor that works with elements from a certain namespace can look for
xmlns attributes, find the shortcut, then work with the shortcut's elements.
XML lets you store arbitrary data in an organized manner, and it lets you design how to lay it out. Sometimes, however, you may wish to explain exactly how you laid things out.
You can do so with a DTD (document type definition), which further lets your XML parser check that the data you are reading is a well-formed XML document and conforms to your specified layout. A DTD is a contract that specifies an XML document's layout.
However, DTD suffers from not being XML: its roots lie in SGML (Standard Generalized Markup Language), forcing you to learn another language. Moreover, DTDs do not work well with namespaces, and they are not particularly good at nailing down exactly what you can put where. A general push is on to replace DTDs with XML Schema.
XML Schema lets you define an XML document's contents similarly to DTDs, but XML Schema does not suffer from DTD's shortcomings.
Most importantly, XML Schema works well with namespaces. XML Schema can specify your document's appearance far more accurately—letting you specify numbers of elements and the legal strings they can contain better than DTDs. Finally, unlike DTDs, an XML Schema document is an XML document, so the same tools that edit and test your XML can edit and test your XML Schema.
<a href="..."> on steroids, lets you link to more than one item and have labels and meanings for each link.
The simplest example resembles the HTML version, with some extra attributes:
<a xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://www.artist.com"/>
<a> to signify links, but you can use XLink in a variety of XML documents so you are not restricted to using
xmlns:xlink attribute gives meaning to the other attributes by announcing that this is XLink. The
xlink:type="simple" attribute tells the XLink interpreter to keep things simple, and
xlink:href="..." represents the real link, just like in HTML.
A more involved sample showing multiple links looks like this:
<artist xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended"> <album xlink:type="locator" xlink:label="album" xlink:href="a.html"/> <song xlink:type="locator" xlink:label="single" xlink:href="b1.html"/> <song xlink:type="locator" xlink:label="single" xlink:href="b2.html"/> </object>
In this example, one
<artist> links to one album and two singles.
XLink uses XML:Base (see below).
The XML Base attribute is analogous to the HTML
<BASE> element. In HTML, you can use
<BASE HREF="http://www.foo.com/"> to instruct the browser to resolve relative URLs using the base given in the
href. XML:Base resembles the
cd command under DOS or Unix. Here's an example of XML:Base working with XLink:
<doc xml:base="http://foo.com/" xmlns:xlink="http://www.w3.org/1999/xlink"> <link xlink:type="simple" xlink:href="new.xml">new</link> </doc>
In the code above, XLink looks for
http://foo.com/new.xml when it must resolve the link.
XPath, a language for selecting an XML document's parts, lets you treat an XML document like a filesystem. XPath queries start with a current element or attribute (much like a current directory within a filesystem) and let you specify other nodes relative to your location.
For example, the path
".." takes you to the parent element.
"aaa" takes you to a child node called
<aaa> and the path
"/aaa/*" jumps to the root element called
<aaa> and selects the elements inside. While that resembles a filesystem, XPath gets much cleverer. For example:
"ccc"selects the fifth
<eee>elements with ancestors (however distant) called
<fff>elements with the attribute
"//ggg/following::*"selects the elements following the first
Xalan, Saxon, Jaxen, and DOM4J let you select nodes using XPath expressions. XPath is particularly valuable here if you use XML to configure an application: rather than digging around your document using DOM or SAX, you can simply request the element you want to read. XPath is the platform upon which XSLT, XPointer, and other technologies are built.
XPointer closely resembles XPath by letting you specify an XML document's parts. Further, XPointer and XPath share a similar syntax. However, XPointer differs from XPath in that the XPointer specifies only a location or contiguous region of the original document; XPath can select many unconnected elements. Compared to XPath, XPointer allows finer control over what you select, down to selecting parts of a text node.
However, XPointer remains controversial because Sun holds a key XPointer patent which the company refuses to freely license. Instead, Sun licenses it on the condition that XPointer improvements go to the W3C (World Wide Web Consortium). With the license, Sun aims to keep XPointer free, or, to read between the lines, to keep Microsoft from embracing and extending this one.
Unfortunately, XML documents can quickly become lengthy. XML is quite verbose, and sometimes we just want to store a lot of data. Editing 20 MB files can be memory hungry, and finding your way around them, nearly impossible. XInclude solves the problem by enhancing XML with an
<xi:include> element that lets you build composite documents.
XInclude lets you specify a file or URI (Uniform Resource Identifier) that should be treated as if it replaced the
XSLT (Extensible Stylesheet Language Transformations) converts any XML document into another XML, HTML, or plaintext document. Some developers find XSLT difficult to grasp because it is a rule-based language, not primarily a procedural or object-based language (although with effort you can make it work in a procedural way).
With XSLT, you specify a set of rules—called templates—that describe how the output document should be created, for example:
<xsl:template match="data"> <table border="1"> <xsl:apply-templates/> </table> <xsl:template>
The above template tells the XSLT processor to find elements in the source document called
<data>, then create an HTML table. You would define other templates to create the table's content.
match="" attribute uses XPath to specify to what elements or attributes the rules apply.
Communicate with XML
This section contains technologies that let computers communicate using XML. Each depends on the technologies outlined in the "Develop with XML" and "XML Building Blocks" sections. For example, SOAP (Simple Object Access Protocol) uses XML Schema, and most SOAP implementations expose you to some XML API. I could have called this section a business-to-business section because, generally speaking, we don't expect customers to be using SOAP much.
Messages and methods represent two closely related XML communication concepts. Methods are synchronous, just like Java method calls (so a method's caller must wait until the method replies before doing anything else). Messages, in contrast, are asynchronous (so the caller sends a message, then carries on; doing so in plain Java requires a new thread, like an email or text message in the real world).
SOAP (Simple Object Access Protocol), an XML-based protocol, uses HTTP or sometimes SMTP (Simple Mail Transfer Protocol) as a transport layer. SOAP adds a few headers to an HTTP request and, where HTTP would post form parameters, SOAP puts a function call request in XML. You can use SOAP in either a method and messaging style.
SOAP heavily uses XML Schema to define the sent data types. The SOAP equivalent of
example.method(42); without headers would look like:
<soap:Envelope xmlns:soap='urn:schemas-xmlsoap-org:soap.v1'> <soap:Body> <example:method xmlns:example='http://www.example.com'> <param>42</param> </example:method> </soap:Body> </soap:Envelope>
A big question when it comes to SOAP is: Why, when we already have RMI (Remote Method Invocation), CORBA/IIOP (Internet Inter-ORB Protocol), DCOM (Distributed Component Object Model), and so on, do we need yet another remote method protocol? The simple answer: The others have fatal flaws when interoperating over the Internet. For example, RMI is Java only, IIOP uses too many ports, making it firewall unfriendly, and DCOM is Windows only.
XML-RPC (Remote Procedure Call) resembles SOAP and shares a similar heritage. SOAP was effectively XML-RPC before being developed by the W3C. Despite that "S" in SOAP stands for "simple," in comparison to XML-RPC, SOAP is anything but simple.
If you plan to implement an XML remote-method protocol, XML-RPC proves much easier to work with than SOAP; however, developers tend to work with third-party libraries where SOAP has much better support than XML-RPC.
As a demonstration of XML-RPC's simplicity, the SOAP call from the SOAP section above in XML-RPC looks like this:
<methodCall> <methodName>example.method</methodName> <params><param><value><param>42</param></value></param></params> </methodCall>
ebXML (electronic business XML), like SOAP, lets you use XML for doing electronic business; however, ebXML is far broader than SOAP. Where SOAP leaves things like service definition and directory look-up to separate areas, ebXML has those areas built right in. Sun's Java support for ebXML compares poorly to the company's SOAP support (while Sun supports ebXML internally, Sun's recent attention seems far more focused on SOAP and its related specifications).
So far in this section we've looked at three protocols—SOAP, XML-RPC, and ebXML—but how do you use them in Java?
Sun's JAXM (Java API for XML Messaging) lets you create messages using SOAP and ebXML. If you plan to change your underlying protocol, JAXM is a good idea.
Sun's JAX-RPC (Java API for XML Remote Procedure Calls) let you access SOAP's method section, as potentially other method protocols. JAXM and JAX-RPC have similar goals except they work on messages and methods, respectively.
SAAJ (SOAP with Attachments API for Java) is another Sun API aimed specifically at SOAP. Generally, you use JAXM or JAX-RPC as a user-level API, then those APIs use SAAJ.
Axis, the Apache SOAP API, has a similar scope to SAAJ in that it only tackles SOAP. It is a follow-on project from the Apache SOAP Project, which in turn builds on IBM's SOAP4J.
Helma, now known as Apache XML-RPC, does for XML-RPC what Axis did for SOAP, (including having many names!)
To work well with Web services, we must agree on how they work and who provides the services. Within the SOAP arena, WSDL (Web Services Definition Language) provides the how and, as you'll see soon, the who by UDDI (Universal Description, Discovery, and Integration).
WSDL lets you define in a document the functionality provided by a server. If you know CORBA, think of WSDL as an IDL (interface definition language) for SOAP.
WSDL can get long-winded, and, generally speaking, you will use tools to generate Java classes from WSDL (or visa versa), so I won't waste space with a long and irrelevant example.
As noted in the WSDL entry, SOAP works best when used with services that give you the who and the how. WSDL serves as the how, while UDDI (Universal Description, Discovery, and Integration) acts as the who. UDDI helps you tell others about your services and find services that you need. UDDI is a business-function directory, with numerous businesses in the UDDI consortium. Three such members—Microsoft, IBM, and SAP—have created UDDI directories. Users search the UDDI directories for service types, or tModels in UDDI speak.
Although UDDI is not a SOAP/XML-only club, since access to UDDI comes through SOAP, the most UDDI registrations will use XML.
JAXR (Java API for XML Registries) allows access from Java to the various XML-based registries like UDDI or ebXML. If you know J2EE (Java 2 Platform, Enterprise Edition) terminology, JAXR does for UDDI what JNDI (Java Naming and Directory Interface) did for LDAP (lightweight directory access protocol). Indeed, JAXR and JNDI solve superficially similar problems; however, JAXR is XML-based. Consequently, where JNDI just stores strings and blobs, leaving the application to understand how to use them, JAXR includes metadata about the objects it stores (from the links between UDDI and XML Schema).
JAXR originally was designed primarily around ebXML; however, SOAP and UDDI have greater vendor support than ebXML, so JAXR's focus has shifted to UDDI.
RDF (Resource Description Framework) lets you encode formatted lists, making it quite different from this section's other technologies that focus on moving bits and bytes.
RDF standardizes list creation, most visibly in news sites that advertise story portals using RDF. With RDF, a portal can aggregate news from many sources, giving users an overview and letting them navigate to the original news sites.
Display with XML
This section explores the XML technologies that let users understand XML data. In contrast to the "Communicate with XML" technologies useful in the business-to-business arena, the technologies below are distinctly customer-oriented.
HTML, long the standard way to display hypertext on the Web, does not comply with XML since HTML tags need not be closed properly and attributes do not need values. XHTML is HTML with XML strictness in how it lays out.
For example, whereas in HTML the following is valid:
It is invalid in XML because the
<i> tags overlap. In XHTML, you would write:
XHTML is being modularized so that rather than having one large set of elements, you would chose the ones you want to use. That helps memory-limited devices like PDAs display subsets of XHTML without needing their own mark-up language like WML (Wireless Markup Language).
HTML and XHTML work fairly well as mark-up languages for on-screen use, but they do possess drawbacks that render them nearly useless for printing. Even if all browsers followed the specs properly, the on-screen view can look different from browser to browser. Second, neither indicates where pages should begin and end or how the pages should be decorated. Developers commonly use tables with HTML to specify page width, and, while this is OK for on-screen use, the result often looks poor on paper. As a result, developers usually employ PDF whenever they require accurate page-based layout, but, because PDF is not an XML-based language, it proves difficult to create a PDF document from XML.
XSL:FO (XSL: Formatting Objects) can solve those problems. Here's a small FO document fragment:
<fo:block font-size="10pt">Subject: <fo:inline font-weight="bold">A simple FO fragment</fo:inline> </fo:block>
FO documents, however, always seem too verbose, so developers tend to generate them with XSLT. You would not edit a large document using raw FO; rather, use a simpler language like DocBook, which you convert into FO using XSLT.
The well-known Apache Group's FOP FO formatter will convert FO into PDF, Postscript, SVG (Scalable Vector Graphics), and many other languages, as well as render the FO into an AWT (Abstract Windowing Toolkit) window. FOP, however, does not cover the entire XSL:FO spec, but it does cover most of the useful bits.
XSL:FO lets you embed graphics in your pages in various formats, but it doesn't define the formats. For an XML-based graphic format you need SVG.
SMIL (Synchronized Multimedia Integration Language, pronounced "smile") is an animation language for creating multimedia presentations on the Web. As an example presentation, the BBC recently created a new, Web-only episode of the cult TV series Dr Who that displays SMIL with RealPlayer.
The following SMIL code displays an icon for 2 seconds:
<smil> <head> <layout> <root-layout width="300" height="200" background-color="white"/> <region id="icon" left="75" top="50" width="32" height="32"/> </layout> </head> <body> <img src="icon.gif" region="icon" dur="2s" /> </body> </smil>
SMIL doesn't define how graphical elements look, but it does specify how they are animated. With SMIL, you are limited to animating text, images, video, and audio.
SVG (Scalable Vector Graphics) aims squarely at vector graphics like WMF (Windows Meta File) files, or Illustrator or Freehand graphics. And when used with SMIL, the two technologies go beyond simple static vector graphics into the realm of Flash movies, in which the graphics can change and interact with the user.
SVG ranges from the simple; this fragment draws a circle:
<circle cx="10" cy="10" r="5" fill="red"/>
To the powerful; this fragment writes text that follows a smile's curve:
<defs><path id="smile" d="M5,5 C5,45 45,45 45,5"/></defs> <text><textPath xlink:href="#smile">some text</textPath></text>
SVG can use SMIL for interaction. To create a rectangle that walks across the screen, use:
<rect y="45" width="10" height="10" fill="red"> <animate attributeName="x" from="0" to="90" dur="5s" repeatCount="indefinite"/> </rect>
In HTML and XHTML, a form mixes what you want to collect with how the form is presented. For example, the
<INPUT> element contains attributes like
style that specify how the field looks, and
size that specifies what is collected. By contrast, XForms separates the how and the why.
XForms are, at the time of this writing, a working draft; a final recommendation is expected around the end of the year, so the following example may change. This form simply prompts users to enter their names:
<xform:input ref="name"> <xform:caption>Name</xform:caption> </xform:input> <xform:submit> <xform:caption>Go</xform:caption> </xform:submit>
For reference, the same form in HTML would look like:
<form action="form.cgi"> <p>Name:</p> <input type="text" size="20" name="name" /> <input type="submit" value="Go" /> </form>
The HTML example may appear simpler, but it is only useful in HTML. The XForm example, in contrast, could prove useful with virtually anything requiring user input. In contrast to HTML forms, XForms, moreover, are not restricted to name-value pairs. Processing XForms produces an XML document.
If you are searching for more information on XForms, don't confuse them with the unrelated graphical user interface (GUI) toolkit by the same name.
This glossary covers 34 different XML technologies with enough detail to help you know which technologies relate to any given problem, as well as how they interconnect. More importantly, by reading this glossary, you understand better how to use them.
Most likely in your next project you won't use all the described technologies, but with your new knowledge, you can pick those most relevant to you and become your own XML expert.
Learn more about this topic
- DOM spec
- SAX Website
- JAXP Website
- JDOM Website
- JDOM JSR
- DOM4J Website
- Jaxen Website
- JAXB Website
- Namespaces Website
- XML Schema spec
- XLink spec
- XMLBase spec
- XPath spec
- XPointer spec
- XPointer Website
- XInclude spec
- XSLT spec
- XSL Website
- SOAP spec
- XML-RPC spec
- ebXML spec
- JAXM Website
- JAXM JSR
- JAX-RPC Website
- JAX-RPC JSR
- SAAJ Website
- Axis Website
- WSDL spec
- UDDI Website
- JAXR JSR
- JAXR Website
- JAXR Tutorial
- RDF Website
- XHTML spec
- XSLFO Website
- SMIL Website
- SMIL spec
- BBC SMIL example
- SVG spec
- XForms spec
- The Java and XML section of JavaWorld's Topical Index offers numerous articles on using XML with Java
- Talk about XML in our XML & Java discussion
- Sign up for JavaWorld's free weekly Enterprise Java email newsletter
- You'll find a wealth of IT-related articles from our sister publications at IDG.net