XML glossary

XML acronyms for Java developers

1 2 3 Page 2
Page 2 of 3

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.

The match="" attribute uses XPath to specify to what elements or attributes the rules apply.

Back to index

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

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).

Back to index


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'>
    <example:method xmlns:example='http://www.example.com'>

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.

Back to index


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:


Back to index


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).

Back to index

APIs (JAXM, JAX-RPC, SAAJ, Axis, Helma)

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!)

Back to index


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.

Back to index


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.

Back to index


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.

Back to index


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.

Back to index

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 <b> and <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).

Back to index


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 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.

Back to index


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:

   <root-layout width="300" height="200" background-color="white"/>
   <region id="icon" left="75" top="50" width="32" height="32"/>
  <img src="icon.gif" region="icon" dur="2s" />

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.

Back to index


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"

You can also access SVG with scripting languages like JavaScript. SVG, much like HTML, possesses its own DOM to respond to events like onclick().

Back to index


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 width and 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">

For reference, the same form in HTML would look like:

<form action="form.cgi">
  <input type="text" size="20" name="name" />
  <input type="submit" value="Go" />

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.

Back to index

XML everywhere

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.

1 2 3 Page 2
Page 2 of 3