Chapter 3 Related Standards Executive Summary Overview of Namespaces Overview of XPath, XPointer, and XQuery Overview of XSLT Overview of XSL Overview of XLink Overview of XML Schema Technical Standards Infrastructure Standards Technical Summary Executive Summary XML documents and DTDs provide the foundation for an evolving Internet document paradigm As people developed XML applications, they naturally identified additional features they wanted to have and troublesome drawbacks they wanted to avoid Such discoveries inspired further standards efforts built on the foundation of XML documents and DTDs As the use of XML has evolved, this process has led to a complicated landscape where old specification efforts languish for extended periods of time and new efforts rapidly achieve acceptance Therefore, identifying the standards relevant to your needs can be something of a challenge Categorizing the various specifications offers a potential aid to navigating the landscape Figure 3-1 presents one potential categorization of XML-related standards It expands on Figure 2-1 by revealing the detailed structure of both the platform standards and the domain standards This categorization can help you identify the depth of understanding you need for any given standard Figure 3-1 Categories of Related Standards The line between platform and domain standards is somewhat fuzzy As a rule of thumb, platform standards potentially add capabilities to XML documents of all types, while domain standards define an XML format to encode information for a narrower purpose In general, a standard that could ultimately affect a majority of XML developers is probably a platform standard Within this category, there are three subcategories Technical standards Standards in this category provide a precise technical foundation for XML processing components to work correctly Without these standards, ambiguity could cause unexpected results when working with documents The most important is XML Infoset, which provides an underlying data model for XML documents Feature standards Standards in this category add new features to the overall XML document paradigm Without these standards, people could not do all of the things that they want to do with XML documents, and the paradigm would be much less valuable Table 3-1 lists the most important feature standards Infrastructure standards Standards in this category provide crucial infrastructure necessary for many XML applications They are low-level applications of the feature standards that provide services used by higher-level applications Standards such as XHTML and XForms specify how to integrate XML with Web technologies Others, such as SOAP and XML Encryption, specify a uniform way to perform common operations Without these standards, XML applications would be incompatible with existing Web applications, and all developers would have to reinvent the same infrastructure It is important to have a thorough understanding of feature standards because they will help you to determine whether XML supplies the capabilities necessary to solve a given business problem On the other hand, most managers only need to understand technical and infrastructure standards at a very high level A general knowledge of technical standards could help you understand the source of a defect in a third-party component that delays a project A general knowledge of infrastructure standards could help you ensure that your developers maximize the use of existing solutions Detailed comprehension of technical and infrastructure standards is usually necessary only for developers working with software components that implement them Figure 3-1 also shows the structure of the domain standards The XML paradigm includes both horizontal and vertical domain standards Horizontal domain standards provide a solution for manipulating information specific to a type of application but used in many industries Examples include portable formats for vector graphics (SVG), multimedia (SMIL), and mathematical expressions (MathML) They generally facilitate common software components across different industries Their applicability depends on whether your application manipulates the particular type of data they describe The vertical domain standards provide formats for describing information specific to a particular industry but used by many types of applications Examples include interoperability formats for finance, health care, and telecommunications They generally facilitate compatibility among systems used within the same industry Their applicability depends on whether your organization works with information from a particular industry Table 3-1 XML Feature Standards Standard XML Namespaces XML Path Language XML Pointer Language XML Query Language XSL Transformations Extensible Stylesheet Language XML Linking Language XML Schema Abbreviation Purpose Namespaces Prevent overlap of names used by different software XPath Address data within a document XPointer Specify locations within a document XQuery Search for data within a set of documents XSLT Transform data from one format to another XSL Present data in a paginated format XLink N/A Link data from different documents Specify more extensive format definition rules than DTDs Table 3-1 lists the most important feature standards The rest of this chapter reviews the important details of these standards At the end of the chapter, there is a summary of key technical and infrastructure standards Overview of Namespaces As you saw in the previous chapter, the primary units of content in XML are elements and attributes Authors distinguish among different types of elements and attributes by assigning them unique names When applications process a document, they associate element content with the corresponding element name and attribute content with the corresponding attribute name As people started to use XML, they realized that organizations and application often use the same name to describe different concepts When these organizations want to exchange information using XML, conflicts may occur A single document often combines information intended for multiple organizations and applications For example, most mail order vendors do not charge customers until they ship the ordered goods Enforcing this policy requires processing the same information with an Accounting application for billing purposes and a Fulfillment application for shipping purposes But what if the Accounting and Fulfillment applications use the term "status" to signify different meanings? Both applications want their respective status data associated with the "Status" element name Such a naming collision has the potential to make life very uncomfortable for developers responsible for specifying the formats of affected documents XML Namespaces, a W3C Recommendation, enables developers to avoid naming collisions by assigning element and attribute names to namespaces Accounting and Fulfillment departments could each have separate namespaces Developers can thereby qualify the use of the "Status" element name with the appropriate namespace How It Works Figure 3-2 illustrates how namespaces can resolve the conflict between the Accounting and Fulfillment applications A Reconciliation Document consolidates billing and shipping information about a given order When the billing status is "invoiced" and the shipping status is "shipped," the document goes to both the Accounting and Fulfillment applications Figure 3-2 Resolving a Conflict with Namespaces When the Accounting application processes the document, it wants to use "Status" as a keyword to signify billing status When the Fulfillment application processes the document, it wants to use "Status" as a keyword to signify shipping status Moreover, the same problem extends to other keywords Example 3-1 shows how to solve this problem using XML Namespaces Example 3-1 Bar Corporation Accounts Payable—Bar Corporation invoice Bar Corporation Loading Dock—Bar Corporation shipped As you can see, attaching the namespace identifier to an element or attribute name with a colon associates that namespace with that element or attribute Before you use a namespace, you associate the namespace prefix with the namespace name, using the reserved XML attribute "xmlns." The namespace name is a Uniform Resource Identifier (URI), essentially indicating that the owner of an Internet resource is the owner of the namespace In this case, "acct" signifies the namespace owned by the Accounting department of Foo Company, and "ful" signifies the namespace owned by the Fulfillment department of Foo Company The example uses the common convention of declaring all namespaces in the document element This convention enables human readers and software processors to determine easily all the namespaces that may be used subsequently Attaching the appropriate prefix to all element and attribute names can be cumbersome To avoid this chore, you can also set a default namespace, which applies to all contained names, as shown in Example 3-2 Example 3-2