The XML-Specification Alphabet Soup.
In 1999, XML (eXtensible Markup Language) generated much talk and a flurry of XML-related recommendations. Along with XML, CSS, DOM, SML Schema, XLink, XPath, XPointer, XSLT, Fragments, Canonical XML, and XQL are some of the terms that have joined the collective Web tongue. It almost makes me nostalgic for the simplicity of HTML. This month, I will summarize the status of the XML recommendations.
The complexity of XML is being driven by two factors. As its name implies, XML is extensible--and therefore extendable. Like HTML, XML derives its DTD (Document Type Definition) from SGML (Standard Generalized Markup Language). But unlike HTML, XML permits the designer to create tags that apply only to that document. The other thing that is complicating XML is the morphing of television (see last month's column) onto the Web platform. The sheer complexity of this feat is demanding more elaborate design solutions. XML is the darling of the Web when the "document" contains XML "data formats," such as vector graphics, e-commerce transactions, and a host of other structured information.
By now you have probably viewed a Web page using XML without noticing anything different about it. The only way to know whether a page is in HTML or XML is to view the source code. HTML pages begin with [less than]HTML[greater than] and XML pages begin with [less than]XML[greater than]. HTML tags describe the appearance of each item on the page. XML tags, on the other hand, describe the function or meaning of items. For example, if I were programming my ZIP code in XML, it would look like this: [less than]zipcode[greater than]02138 [less than]/zipcode[greater than], which would tell not only me, but also the computer, that this is a ZIP code. Although these are not HTML tags, they can be rendered (displayed by your browser) to look just like HTML.
The World Wide Web Consortium (W3C) has made the specifications for XSLT (http://www.w3.org/TR/xslt) and XPath (http:// www.w3.org/TR/xpath) available in both HTML and XML formats, if you would like to compare the two side by side.
Oodles of Specifications
November was a busy month for the W3C. First, on November 2, the last call for the working draft of "The Platform for Privacy Preferences 1.0" was released. This was followed by the November 5 release of "User Agent Accessibility Guidelines 1.0," "XML Schema Part 1: Structures," and "XML Schema Part 2: Datatypes." Then, on November 9, the W3C released working drafts for the XMLSignature Core Syntax and Processing. On November 15, working drafts were released for Canonical XML, Synchronized Multimedia Integration Language (SMIL--pronounced "smile" and code-named SMIL Boston), and the SMIL Document Object Model. Finally, on November 16, the consortium released two specifications, XSL Transformations (XSLT) and XML Path Language (XPath), as recommendations.
As the level of technical specificity grows, so does the level of detail that is driving the creation of these specifications. Let me use Canonical XML as an example. The abstract describes it as "a subset of the information contained in an XML document and a syntax for expressing that subset. This syntax, called Canonical XML, is designed to encode the logical structure of XML documents; two XML documents whose Canonical XML form is identical will be considered equivalent for the purposes of many applications." And what does this mean in English? In the remaining space in this month's column, I will explain and highlight the specifications that are generating the most interest in the XML community.
XSLT and XPath
Certainly the greatest fanfare is being accorded to XSLT and XPath. "As the Web develops into a structured data space, and the tools used to access the Web grow more varied, the need for flexibility in styling and structure is essential," explained 'Vincent Quint, W3C user interface domain leader and staff contact for the XSL Working Group. "With XSLT and XPath, we're closer to delivering rich, structured data content to a wider range of devices."
XSLT is designed for use as part of XSL, which is a style sheet language for XML. XSLT makes it possible for one XML document to be transformed into another according to an XSL style sheet. As part of the document transformation, XSLT uses XPath to address parts of an XML document that an author wishes to transform. XPath is also used by another XML technology, XPointer, to specify locations in an XML document. "What we've learned in developing XPath will serve other critical XML technologies already in development," noted Daniel Veil- lard, W3C staff contact for the XML Linking Working Group.
"Anyone using XML can now take advantage of XSLT, a powerful new tool for manipulating, converting, or styling documents," declared W3C director Tim Berners-Lee.
Works in Progress
SMIL is written as an XML application, and SMIL 1.0 is a W3C specification. As the name implies, SMIL is all about multimedia elements. SMIL permits the XML author to position and synchronize multimedia elements on the screen. Only a simple text editor is required to create SMLL. An excellent tutorial is available at http:// www.helio.org/products/smil/tutorial.
The first SMIL Boston working draft was released last August, and the most recent was released on November 15. There are two key concepts addressed by SMIL Boston. First is the separation of SMIL into nine modules, which include, among others, the content control and meta-information modules. Profiles are then created with sets of modules. For example, in SMIL Boston a slide presentation could be timed so that bullet points appear in sequence at specified time intervals, changing color as they become the focus of attention.
The proposed specification includes a number of XML tags and attributes that could be embedded into XML applications. One idea is a timesheet that could be layered on top of a document. Similar to a style sheet, it controls the timing of events rather than the presentation attributes. SMIL Boston also introduces an animation framework that corresponds with the timesheet.
XML-Signature Core Syntax and Processing refers to the encoding of digital signatures using XML. The structure allows for both embedded and detached signatures. An embedded signature can include the signature within the signed object or it can embed the signed object within the signature. A detached signature allows the signature to be independent of the object. The processing structure allows for switching between embedded and detached signatures without necessarily invalidating the signature. Such signatures can provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML document that includes the signature or elsewhere.
The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by browsers. In turn, the browser can inform users of site practices and, ultimately, generate automatic decision making. For example, a user might specify the degree of privacy that is required when visiting a site, and the browser could communicate that a certain site does not meet that requirement. This would free the visitor from reading the privacy policies for each site. The P3P policies use an XML encoding of the P3P vocabulary for expressing privacy practices. It does not provide a technical mechanism for ensuring that sites act according to their policies. Products implementing this specification may ultimately provide some assistance, but this is outside the specification. The specification does not outline privacy protection when data are transferred, nor does it address the storage of personal data.
Scramble for Standards
This fast and furious growth of specifications and standards is causing concern for XML interoperability. A new organization, the Organization for the Advancement of Structured Information Standards (OASIS; http://www.sml.org), has emerged as companies scramble to make the rapidly growing scheme of XML standards actually work. This begs the question: Why do we need another vendor-neutral forum for an international XML consortium when we already have the W3C? I hope we are not heading toward another standards war in the tradition of HTML (i.e., Netscape Navigator vs. Internet Explorer).
Robin Peek is associate professor at the Graduate School of Library and Information Science at Simmons College.
|Printer friendly Cite/link Email Feedback|
|Date:||Jan 1, 2000|
|Previous Article:||KOZ.com to Supply Software for K-12 Education Portal.|
|Next Article:||NuvoMedia and SoftBook Press Jointly Propose OEB File Format Specification.|