The World Wide Web Consortium (W3C), based in Cambridge, Massachusetts, is an international association of companies interested in maintaining standards for the World Wide Web. (You learned a little about the W3C in Chapter 2.)
W3C standards are the result of global input refined through an extensive process that eventually leads to consensus. The steps in the W3C specification approval process include the following:
The W3C has created many Recommendations during its lifetime. HTML and CSS are two of the most widely used. In 1996, a group of Web-savvy SGML gurus submitted an idea to the W3C for a slimmed-down version of SGML that would fit easily into Web browsers or server-side applications. This effort became known as XML.
XML 1.0 was formally adopted as a W3C Recommendation in February 1998. To create the XML Recommendation, the W3C XML Working Group started with SGML, removed all the optional features, and streamlined the syntax. This resulted in a small, terse syntax that small, fast parsers can process. As you learned in earlier chapters, XML provides only a way of describing your data; it doesn't have features for processing the data. XML is small, and it will stay that way. However, many users have found the need to do certain common types of processing, so the W3C is working on standards to use with XML to provide more processing functionality.
In this section, we'll look at the standards established by the W3C that support XML and make programming it more efficient. Figure 3-1 illustrates how these various standards are related.
Figure 3-1. The W3C publishes a rich set of standards that support XML. By plugging into the base spec (DOM), an implementer can select specific technologies for a particular task.
An example of a standard that addresses the need for better processing functionality is one that deals with linking. XML expresses information in terms of hierarchical relationships. An element can have children, which, in turn, can have their own children. The structure of an XML document describes only this model. Some data structures, however, have nonhierarchical relationships; an object might have a relationship with another object in a different location. This type of relationship must be expressed in terms of a link rather than as a parent-child relationship.
Two W3C Working Drafts provide a standard way of representing linking: XLink and XPointer. I can best illustrate these specifications with an example. Consider the HTML anchor element, <A>. The element's form looks like this:
<A HREF= "http://architag.com/solutions/senior.html#btravis"> Brian Travis</A> |
This element consists of two distinct pieces:
What if we want to indicate a different processing semantic to our own links? For example, what if I want to create a link that allows a user to select one destination from a number of different destinations? A link in a document that refers to Beethoven might lead to different places, depending on what the user wants to see. It could lead to a biography of the composer Ludwig van Beethoven, a symphony score by the composer, or a showing of Beethoven, the movie about a slobbering dog.
If I want to include such a link on my page, I need to create a script that shows a pop-up window, allows the user to select an option, and then goes to the selected destination. XLink provides this functionality. A browser that supports XLink can do such one-to-many links declaratively, without requiring special scripting.
XLink also allows inline links. What if I want to include bits and pieces of many different documents in my document? Inline links allow me to grab several documents from different locations and include them all on the same page. In this way, I can have a page consisting of only a set of links. I think XLink offers the <A> tag on steroids.
By the same token, XPointer works like the HREF attribute on steroids. In the previous example, the URL points to a location inside the document referenced. This bookmark pointer simply causes the browser to scroll to a marked location after the page is loaded.
But what if I don't want to see the whole page? What if I want to include only the paragraphs concerning btravis and not the rest of the document? The XPointer syntax allows you to target a portion of a page with more granularity than the HREF can. For example, you can present an XPointer string to tell an XLink tag that you want to include only the third through the sixth paragraphs of a section with an identifier of chapter2.
A schema describes the structure of an information set. XML 1.0 specifies a schema syntax named a document type definition (DTD). The DTD is a relic of SGML and as such does not have modern data processing capabilities built in. The DTD is great for expressing textual documents such as technical manuals, business plans, and training guides. However, the DTD schema syntax has some limitations when XML is used to transmit real-time database data and business documents between trading partners in an e-commerce environment.
Shortly after the W3C XML Working Group finalized the XML 1.0 Recommendation, several groups made formal submissions to the W3C for a schema syntax that extends the capabilities of the DTD. These were XML Data, Document Definition Markup Language (DDML), Schema for Object-oriented XML (SOX), and Document Content Description for XML (DCD). I discuss XML schemas in depth in Chapter 4.
Namespaces indicate to the XML processor where to find the structural rules (the schema) to apply to a document. A namespace declaration points to a resource containing the schema that describes the document.
Let's look at how a namespace works in practice. In the preceding XLink and XPointer discussion, I mentioned that you can link to pages in a more granular way. Suppose I pull in several different fragments from various XML documents on the Web. Each of these documents might use the same element name, but each element name might imply something different to each particular document creator. For example, I want to grab three paragraphs from George's document and four paragraphs from Martha's document and make them all appear on a single page. I'll then write a style sheet that formats the finished page to make it presentable in the browser.
Well, George has an element named date that represents a day of the week:
<date>Feb 13, 2000</date> |
Martha also has a date element, but Martha thinks a date is a night on the town with George:
<date>Dinner, then a movie</date> |
If I include both these elements in the same virtual document, I'll have what is called a namespace collision.
Namespaces provide a way of differentiating elements in a single document. To prevent a namespace collision, I declare two namespaces that point to the two schemas that describe the structure of the two documents. Then I prefix each element with the appropriate namespace prefix:
<document xmlns:george="http://no1prez.com/schemas/schema1.xdr" xmlns:martha="http://schemas.martha.com/funstuff.xdr"> ... <george:date>Feb 13, 2000</george:date> ... <martha:date>Dinner, then a movie</martha:date> ... </document> |
I've thereby eliminated the identical element names. Once I prefix these elements, I can use a style sheet to create two rules to identify the elements independently, and an application can process each element separately. I'll discuss namespaces further in Chapter 5.
It's important to note that the XML 1.0 Recommendation doesn't provide any standard way of formatting the content in XML documents. Enter XSL, the Extensible Stylesheet Language. The W3C XSL Working Group was formed by some of the same people who worked on the Document Style Semantic Specification Language (DSSSL). DSSSL is an ISO standard that provides a syntax for adding style semantics to an SGML document. DSSSL is terribly complex because of the intricate page-definition tasks it must perform. The XSL Working Group used DSSSL as a starting point for adding semantics but quickly decided that DSSSL would need to change too much, so the group redirected its focus.
To that end, XSL consists of two main functions: XML document transformation and formatting object interpretation. The main purpose of XSL is to convert XML documents into some formatted representation. The latter function—interpreting the formatting object string—is really only necessary if you are creating printed documents. (By printed, I mean on paper or a paper equivalent, such as a Web site or a CD-ROM image.)
As the XSL standard progressed, the Working Group realized that document transformation could have a lot of value even if an XML document was never rendered for human consumption. The XSL committee extracted the transformation part from XSL and created a new standard, XSL Transformations (XSLT). XSLT is a W3C Recommendation, and several software vendors have created XSLT processors to work with the spec. XSLT is a general-purpose transformation engine that you can use in many places. You should learn XSLT if you use XML in any serious way.
The W3C extracted the pattern-matching syntax from XSL and created the XPath specification. XPath provides a way to describe the structure of a source document so that you can transform the document. I discuss both XSLT and XPath in depth in Chapter 6.
Many people in the XML community felt the need for a standard way to query a set of XML documents. This standard would be equivalent to the Structured Query Language (SQL) used to query relational databases from many different vendors.
Currently, there is no standard way of querying the contents of a collection of XML documents. The XML Query Language (XQL) Working Group is currently working on a specification to do just that: provide a standardized syntax that looks into the structure of a database of XML documents and returns a result set that can be processed in a standard way.
All the specifications I've mentioned so far can be included in an implementation that processes XML documents. The W3C formed a committee to work on a model that described an XML document for the purpose of developing standardized applications. The Document Object Model (DOM) specification is the result of that committee's work.
The DOM provides a standard set of interfaces that expose the properties and methods of XML and HTML documents. Although the W3C DOM is an agreed-upon standard, the developers left out implementation specifics, preferring that individual implementers do the heavy lifting. I'll discuss the DOM in Chapter 5.