Another abandoned server code base... this is kind of an ancestor of taskrambler.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

1389 lines
58 KiB

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>XSLT Requirements</title>
<style type="text/css">
p.element-syntax { border: solid thin }code { font-family: monospace }
.tabheader { background-color: #e0e0e0 }
.row0 { background-color: #f0f0f0 }
.row1 { background-color: white }
.java-class {
font-family: monospace;
white-space: pre;
}
.lit {font-family:monospace}
.req {font-size:90%; font-weight:bold}
.id {font-size:80%}
.p0 {color:red; font-weight:bold}
.p1 {color:blue; font-weight:bold}
.p2 {color:#999999; font-weight:bold}
.p3 {color:green; font-weight:bold}
.r0 {background:white}
.r1 {background:white}
.s1 {margin-left: 20pt}
</style>
<link rel="stylesheet" type="text/css"
href="http://www.w3.org/StyleSheets/TR/W3C-WD">
</head>
<body>
<div class="head">
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/WWW/w3c_home"
alt="W3C" height="48" width="72"></a>
<h1>XSLT Requirements<br>
Version 2.0</h1>
<h2>W3C Working Draft 14 February 2001</h2>
<dl>
<dt>This version:</dt>
<dd><a
href="http://www.w3.org/TR/2001/WD-xslt20req-20010214">http://www.w3.org/TR/2001/WD-xslt20req-20010214</a>
<br>
(available in <a
href="http://www.w3.org/TR/2001/WD-xslt20req-20010214.xml">XML</a> or <a
href="http://www.w3.org/TR/2001/WD-xslt20req-20010214.html">HTML</a>)</dd>
<dt>Latest version:</dt>
<dd><a
href="http://www.w3.org/TR/xslt20req">http://www.w3.org/TR/xslt20req</a>
<br>
</dd>
<dt>Editors:</dt>
<dd>Steve Muench (Oracle) <a
href="mailto:Steve.Muench@oracle.com">&lt;Steve.Muench@oracle.com&gt;</a>
<br>
Mark Scardina (Oracle) <a
href="mailto:Mark.Scardina@oracle.com">&lt;Mark.Scardina@oracle.com&gt;</a>
<br>
</dd>
</dl>
<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
©2001 <a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
href="http://www.lcs.mit.edu/"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
href="http://www.inria.fr/"><abbr lang="fr"
title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
<a
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
licensing</a> rules apply.</p>
<hr title="Separator for header">
</div>
<h2><a name="abstract">Abstract</a></h2>
<p>This document describes the requirements for the XSLT 2.0
specification.</p>
<h2><a name="status">Status of this document</a></h2>
<p>This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest status of
this document series is maintained at the W3C. This document is the first
public XSLT 2.0 Requirements working draft.</p>
<p>This is a W3C Working Draft for review by W3C Members and other interested
parties. It is a draft document and may be updated, replaced or made obsolete
by other documents at any time. It is inappropriate to use W3C Working Drafts
as reference material or to cite them as other than "work in progress". This
is work in progress and does not imply endorsement by the <a
href="http://www.w3.org/Consortium/Member/List">W3C membership</a>.</p>
<p>This document has been produced as part of the <a
href="http://www.w3.org/Style/Activity">W3C Style activity</a>, following the
procedures set out for the W3C Process. The document has been written by the
<a href="http://www.w3.org/Style/XSL/Group/">XSL Working Group</a> (<a
href="http://cgi.w3.org/MemberAccess/AccessRequest">W3C members only</a>). The
goals of the XSL Working Group are discussed in the <a
href="http://www.w3.org/Style/2000/xsl-charter.html">XSL Working Group
charter</a>. The XSL Working Group feels that the contents of this Working
Draft are relatively stable, and therefore encourages feedback on this
version.</p>
<p>Comments on this document should be sent to the W3C mailing list <a
href="mailto:xsl-editors@w3.org">xsl-editors@w3.org</a> (archived at <a
href="http://lists.w3.org/Archives/Public/xsl-editors/">
http://lists.w3.org/Archives/Public/xsl-editors/</a>). A list of current W3C
Recommendations and other technical documents can be found at <a
href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>
<h2><a name="contents">Table of contents</a></h2>
1 <a href="#section-Goals">Goals</a> <br>
2 <a href="#section-Requirements">Requirements</a> <br>
3 <a href="#section-References">References</a> <br>
<h3>Appendices</h3>
<hr>
<h2><a name="section-Goals"></a>1 Goals</h2>
<p>XSLT 2.0 has the following goals:</p>
<ul>
<li>Simplify manipulation of XML Schema-typed content</li>
<li>Simplify manipulation of string content</li>
<li>Support related XML standards</li>
<li>Improve ease of use</li>
<li>Improve interoperability</li>
<li>Improve i18n support</li>
<li>Maintain backward compatibility</li>
<li>Enable improved processor efficiency</li>
</ul>
<p>In addition, the following are explicitly <i>not</i> goals:</p>
<ul>
<li>Simplifying the ability to parse unstructured information to produce
structured results.</li>
<li>Turning XSLT into a general-purpose programming language</li>
</ul>
<h2><a name="section-Requirements"></a>2 Requirements</h2>
<table border="0" cellspacing="0" width="100%">
<tbody>
<tr class="r1">
<td colspan="1" valign="top" align="right"><b>1</b></td>
<td colspan="2"><u class="p0">Must Support the XML "Family" of
Standards</u> <br>
<p>As part of the evolving family of XML standards, XSLT 2.0 MUST
support the W3C XML architecture by integrating well with other
standards in the family.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>1.1</b></td>
<td colspan="1"><u class="p0">Must Maintain Backwards Compatibility with
XSLT 1.1</u> <br>
<p>Any stylesheet whose behavior is fully defined in XSLT 1.1 and
which generates no errors will produce the same result tree under XSLT
2.0</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>1.2</b></td>
<td colspan="1"><u class="p0">Must Match Elements with Null Values</u>
<br>
<p>A stylesheet SHOULD be able to match elements and attributes whose
value is explicitly <code>null</code>.</p>
<blockquote>
<p><b>Ed. Note: </b> <i>Just</i> matching
<code>@xsi:null="true"</code> would find elements with this
attribute even if the element actually had content like:</p>
<div class="java-class">
&lt;foo xsi:null="true"&gt;SomeValue&lt;/foo&gt;</div>
<br>
or used the xsi:null when the element did not allow its content to
be nullable, both of which are invalid.</blockquote>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>1.3</b></td>
<td colspan="1"><u class="p1">Should Allow Included Documents to
"Encapsulate" Local Stylesheets</u> <br>
<p>XSLT 2.0 SHOULD define a mechanism to allow the templates in a
stylesheet associated with a <i>secondary</i> source document, to be
imported and used to format the included fragment, taking precedence
over any applicable templates in the current stylesheet.</p>
<table border="0">
<tbody>
<tr>
<td colspan="1"><u><b>Use Case</b></u></td>
</tr>
<tr>
<td colspan="1"><p>When a MATHML document is included in the
current source document, that MATHML fragment could already
contain its own &lt;?xml-stylesheet?&gt; indicating
appropriate templates to properly style the Math.</p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>1.4</b></td>
<td colspan="1"><u class="p2">Could Support Accessing Infoset Items for
XML Declaration</u> <br>
<p>A stylesheet COULD be able to access information like the version
and encoding from the XML declaration of a document.</p>
<table border="0">
<tbody>
<tr>
<td colspan="1"><u><b>Use Case</b></u></td>
</tr>
<tr>
<td colspan="1"><p>A stylesheet should be able to set the output
encoding to use the same encoding as the input document.</p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>1.5</b></td>
<td colspan="1"><u class="p2">Could Provide QName Aware String
Functions</u> <br>
<p>Users manipulating documents (e.g. stylesheets, schemas) that have
QName-valued element or attribute content need functions that take a
string containing a QName as their argument, convert it to an expanded
name using either the namespace declarations in scope at that point in
the stylesheet, or the namespace declarations in scope for a specific
source node, and return properties of the expanded name such as its
namespace URI and local name.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>1.6</b></td>
<td colspan="1"><u class="p2">Could Enable Constructing a Namespace with
Computed Name</u> <br>
<p>Provide an <code>&lt;xsl:namespace&gt;</code> analog to
<code>&lt;xsl:element&gt;</code> for constructing a namespace node
with a computed prefix and URI.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>1.7</b></td>
<td colspan="1"><u class="p2">Could Simplify Resolving Prefix Conflicts
in QName-Valued Attributes</u> <br>
<p>XSLT 2.0 COULD simplify the renaming of conflicting namespace
prefixes in result tree fragments, particularly for attributes
declared in a schema as being QNames. Once the processor knows an
attribute value is a QName, an XSLT processor should be able to rename
prefixes and generate namespace declarations to preserve the semantics
of that attribute value, just as it does for attribute names.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>1.8</b></td>
<td colspan="1"><u class="p2">Could Support XHTML Output Method</u> <br>
<p>Complementing the existing output methods for <code>html</code>,
<code>xml</code>, and <code>text</code>, an xhtml output method could
be provided to simplify transformations which target XHTML output.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top" align="right"><b>2</b></td>
<td colspan="2"><u class="p0">Must Improve Ease of Use</u> <br>
<p>XSLT 2.0 MUST address frequently requested enhancements to make
using XPath even more straightfoward for handling common use
cases.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.1</b></td>
<td colspan="1"><u class="p0">Must Allow Matching on Default Namespace
Without Explicit Prefix</u> <br>
<p>Many users stumble trying to match an element with a default
namespace. They expect to be able to do something like:</p>
<div class="java-class">
&lt;xsl:stylesheet version="1.0" <br>
         xmlns:xsl="http://www.w3.org/1999/XSL/Transform"<br>
         xmlns="urn:myuri"&gt;<br>
  &lt;!-- Expect this matches &lt;foo&gt; in default namespace
--&gt;<br>
  &lt;xsl:template match="foo"&gt;</div>
<br>
<p>thinking that leaving off the prefix from the <code>foo</code>
element name, that it will match <code>&lt;foo&gt;</code> elements in
the default namespace with the URI of <code>urn:myuri</code>. Instead,
they are required to assign a non-null prefix name to their namespace
URI and then match on "<code>someprefix:foo</code>" instead, which has
proven to be far from obvious. XSLT 2.0 SHOULD provide an explicit way
to handle this scenario to avoid further user confusion.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.2</b></td>
<td colspan="1"><u class="p0">Must Add Date Formatting Functions</u>
<br>
<p>One of the more frequent requests from XSLT 1.0 users is the
ability to format date information with similar control to XSLT's
<code>format-number()</code>. XML Schema introduces several kinds of
date and time datatypes which will further increase the demand for
date formatting during transformations. Functionality similar to that
provided by <a
href="http://java.sun.com/products/jdk/1.1/docs/api/java.text.SimpleDateFormat.html">java.text.SimpleDateFormat</a>.
A date analog of XSLT's named <code>xsl:decimal-format</code> may be
required to handle locale-specific date formatting issues.</p>
<table border="0">
<tbody>
<tr>
<td colspan="1"><u><b>Use Case</b></u></td>
</tr>
<tr>
<td colspan="1"><ol>
<li><p>Given an XML element like: <code>&lt;Period
start="2000-05-07" end="2000-05-13"/&gt;</code></p>
<p>Format it as: <code>Invoice: 7 May 2000 - 13 May
2000</code></p>
</li>
<li><p>Given the same element above, format it according to
the current locale as:</p>
<div class="java-class">
Fattura: 7 Maggio 2000 - 13 Maggio 2000</div>
<br>
</li>
</ol>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.3</b></td>
<td colspan="1"><u class="p0">Must Simplify Accessing Id's and Key's in
Other Documents</u> <br>
<p>Currently it is cumbersome to lookup nodes by <code>id()</code> or
<code>key()</code> in documents other than the source document. Users
must first use an <code>xsl:for-each</code> instruction, selecting the
desired <code>document()</code> to make it the current node, then
relative XPath expressions within the scope of the
<code>xsl:for-each</code> can refer to <code>id()</code> or
<code>key()</code> as desired.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.4</b></td>
<td colspan="1"><u class="p1">Should Provide Function to Absolutize
Relative URIs</u> <br>
<p>There SHOULD be a way in XSLT 2.0 to create an absolute URI. The
functionality should allow passing a node-set and return a string
value representing the absolute URI resolved with respect to the base
URI of the current node.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.5</b></td>
<td colspan="1"><u class="p1">Should Include Unparsed Text from an
External Resource</u> <br>
<p>Frequently stylesheets must import text from external resources.
Today users have to resort to extension functions to accomplish this
because XSLT 1.0 only provides the <code>document()</code> function
which, while useful, can only read external resources that are
well-formed XML documents.</p>
<table border="0">
<tbody>
<tr>
<td colspan="1"><u><b>Use Case</b></u></td>
</tr>
<tr>
<td colspan="1"><p>Given an XML document like:</p>
<div class="java-class">
&lt;section&gt;<br>
  &lt;para&gt;The code for the example looks like
this:&lt;/para&gt;<br>
  &lt;example&gt;<br>
    &lt;external-file href="ParseXML.java"/&gt;<br>
  &lt;/example&gt;<br>
&lt;/section&gt;</div>
<br>
<p>Format the section and include the source of the sample
code from the external file in the output.</p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.6</b></td>
<td colspan="1"><u class="p1">Should Allow Authoring Extension Functions
in XSLT</u> <br>
<p>As part of the XSLT 1.1 work done on extension functions, a
proposal to author XSLT extension functions in XSLT itself was
deferred for reconsideration in XSLT 2.0. This would allow the
functions in an extension namespace to be implemented in "pure" XSLT,
without resulting to external programming languages.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.7</b></td>
<td colspan="1"><u class="p1">Should Output Character Entity References
Instead of Numeric Character Entities</u> <br>
<p>Users have frequently requested the ability to have the output of
their transformation use (named) character references instead of the
numeric character entity. The ability to control this preference as
the level of the whole document is sufficient. For example, rather
than seeing <code>&amp;#160;</code> in the output, the user could
request to see the equivalent <code>&amp;nbsp;</code> instead.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.8</b></td>
<td colspan="1"><u class="p1">Should Construct Entity Reference by
Name</u> <br>
<p>Analogous to the ability to create elements and attributes, users
have expressed a desire to construct named entity references.</p>
<blockquote>
<p><b>Ed. Note: </b>Does this require a change to the data
model?</p>
</blockquote>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.9</b></td>
<td colspan="1"><u class="p1">Should Support for Unicode String
Normalization</u> <br>
<p>For reliable string comparison of Unicode strings, users need the
ability to apply Unicode normalization before comparing the
strings.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.10</b></td>
<td colspan="1"><u class="p1">Should Standardize Extension Element
Language Bindings</u> <br>
<p>XSLT 1.1 undertook the standarization of language bindings for XSLT
extension functions. For XSLT 2.0, analogous bindings SHOULD be
provided for extension elements.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.11</b></td>
<td colspan="1"><u class="p2">Could Improve Efficiency of
Transformations on Large Documents</u> <br>
<p>Many useful transformations take place on large documents
consisting of thousands of repeating "sub-documents". Today
transformations over these documents are impractical due to the need
to have the entire source tree in memory. Enabling "progressive"
transformations, where the processor is able to produce progressively
more output as more input is received, is tantamount to avoiding the
need for XSLT processors to have random access to the entire source
document. This might be accomplished by:</p>
<ul>
<li>Identifying a core subset of XPath that does not require random
access to the source tree, or</li>
<li>Consider a "transform all subtrees" mode where the stylesheet
says, "Apply the transformation implied by this stylesheet to each
node that matches <code>XXX</code>, considered as the root of a
separate tree, and copy all the results of these
mini-transformations as separate subtrees on to the final result
tree."</li>
</ul>
<table border="0">
<tbody>
<tr>
<td colspan="1"><u><b>Use Case</b></u></td>
</tr>
<tr>
<td colspan="1"><p>Transforming an XML document representing the
daily closing prices of NASDAQ stocks for 1999 like the
example below (over 1.3 millon
<code>&lt;ClosingQuote&gt;</code> sub-elements) to produce a
comma-separated list of Ticker, Date, and Closing Price.</p>
<div class="java-class">
&lt;YearOfNasdaqCloses Year="1999"
TotalSecurities="5207"&gt;<br>
  &lt;ClosingQuote Ticker="AAABB"&gt;<br>
    &lt;Date&gt;01/01/1999&lt;/Date&gt;<br>
    &lt;Price&gt;6.25&lt;/Price&gt;<br>
    &lt;Percent&gt;0.5&lt;/Percent&gt;<br>
  &lt;/ClosingQuote&gt;<br>
  &lt;!-- 1,353,818 Additional Entries Removed --&gt;<br>
  &lt;ClosingQuote Ticker="ZVXI"&gt;<br>
    &lt;Date&gt;12/31/1999&lt;/Date&gt;<br>
    &lt;Price&gt;16.10&lt;/Price&gt;<br>
    &lt;Percent&gt;-1.05&lt;/Percent&gt;<br>
  &lt;/ClosingQuote&gt;<br>
&lt;/YearOfNasdaqCloses&gt;</div>
<br>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.12</b></td>
<td colspan="1"><u class="p2">Could Support for Reverse IDREF
attributes</u> <br>
<p>Given a particular value of an <code>ID</code>, produce a list of
all elements that have an <code>IDREF</code> or <code>IDREFS</code>
attribute which refers to this ID.</p>
<blockquote>
<p><b>Ed. Note: </b>This functionality can be accomplished using the
current <code>&lt;xsl:key&gt;</code> and <code>key()</code>
mechanism.</p>
</blockquote>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.13</b></td>
<td colspan="1"><u class="p2">Could Support for Case-Insensitive
Comparisons</u> <br>
<p>XSLT 2.0 could expand its comparison functionality to include
support for case-insensitive string comparison.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.14</b></td>
<td colspan="1"><u class="p2">Could Support Lexigraphic String
Comparisons</u> <br>
<p>We don't let users compare strings like <code>$x &gt;
'a'</code>.</p>
<blockquote>
<p><b>Ed. Note: </b>i18n issues.</p>
</blockquote>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.15</b></td>
<td colspan="1"><u class="p2">Could Allow Comparing Nodes Based on
Document Order</u> <br>
<p>Support the ability to test whether one node comes before another
in document order.</p>
<blockquote>
<p><b>Ed. Note: </b>Need a Use Case for this.</p>
</blockquote>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.16</b></td>
<td colspan="1"><u class="p2">Could Improve Support for Unparsed
Entities</u> <br>
<p>In XSLT 1.0 there is an asymmetry in support for unparsed entities.
They can be handled on input but not on output. In particular, there
is no way to do an identity transformation that preserves them. At a
minimum we need the ability to retrieve the Public ID of an unparsed
entity.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.17</b></td>
<td colspan="1"><u class="p2">Could Allow Processing a Node with the
"Next Best Matching" Template</u> <br>
<p>In the construction of large stylesheets for complex documents, it
is often necessary to construct templates that implement special
behavior for a particular instance of an element, and then apply the
normal styling for that element. Currently this is not possible
because <code>&lt;xsl:apply-templates/&gt;</code> specifies that for
any given node only a single template will be selected and
instantiated.</p>
<p>Currently the processor determines a list of matching templates and
then discards all but the one with the highest priority. In order to
support this requirement, the processor would retain the list of
matching templates sorted in priority order. A new instruction, for
example <code>&lt;xsl:next-match/&gt;</code>, in a template would
simply trigger the next template in the list of matching templates.
This "next best match" recursion naturally bottoms out at the builtin
template which can be seen as the lowest priority matching template
for every match pattern.</p>
<table border="0">
<tbody>
<tr>
<td colspan="1"><u><b>Use Case</b></u></td>
</tr>
<tr>
<td colspan="1"><p>Consider a large, complex stylesheet for a
particular document type. In order to support a new
application, the schema designer for that document type adds a
new global attribute, that is an attribute allowed on every
element in the schema. For example, consider the addition of a
global attribute named <code>diff</code> for marking changes
made between one version of a document and another. You must
now augment your stylesheet to support this new behavior.</p>
<p>One would like to add a single new template, or a small
number of templates, that would implement the new
functionality for the entire doctype. Something like this:</p>
<div class="java-class">
&lt;xsl:template match="*[@diff='new']"&gt;<br>
  &lt;div class="new"&gt;<br>
    &lt;!-- do whatever you would have done for this element
--&gt;<br>
  &lt;/div&gt;<br>
&lt;/xsl:template&gt;<br>
<br>
&lt;xsl:template match="para"&gt;<br>
  &lt;p&gt;<br>
    &lt;xsl:apply-templates/&gt;<br>
  &lt;/p&gt;<br>
&lt;/xsl:template&gt;<br>
</div>
<br>
<p>When passed a document that contains <code>&lt;p
diff='new'&gt;...&lt;/p&gt;</code>, it would produce:</p>
<div class="java-class">
&lt;div class="new"&gt;<br>
&lt;p&gt;...&lt;/p&gt;<br>
&lt;/div&gt;<br>
</div>
<br>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>2.18</b></td>
<td colspan="1"><u class="p2">Could Make Coercions Symmetric By Allowing
Scalar to Nodeset Conversion</u> <br>
<p>Presently, no datatype can be coerced or cast to a node-set. By
allowing a string value to convert to a node-set, some user "gotchas"
could be avoided due.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top" align="right"><b>3</b></td>
<td colspan="2"><u class="p0">Must Support XML Schema</u> <br>
<p><a href="http://www.w3.org/TR/xmlschema-1/">XML Schema:
Structures</a> and <a href="http://www.w3.org/TR/xmlschema-2/">XML
Schema: Datatypes</a> enable users to define and use both simple and
structured types and associate them to elements and attributes in a
schema. XSLT 2.0 MUST provide support for the common operations
needed for matching and construction of transformed documents based on
a source document containing these typed elements and attributes.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>3.1</b></td>
<td colspan="1"><u class="p0">Must Simplify Constructing and Copying
Typed Content</u> <br>
<p>It MUST be possible to construct XML Schema-typed elements and
attributes. In addition, when copying an element or an attribute to
the result, it should be possible to preserve the type during the
process.</p>
<blockquote>
<p><b>Ed. Note: </b>Use Case needs work.</p>
</blockquote>
<table border="0">
<tbody>
<tr>
<td colspan="1"><u><b>Use Case</b></u></td>
</tr>
<tr>
<td colspan="1"><ol>
<li>
<div class="java-class">
&lt;href
xsi:type="urireference"&gt;foo.xml&lt;/href&gt;</div>
<br>
</li>
<li>
<div class="java-class">
&lt;href xsl:type="urireference"&gt;&lt;xsl:value-of
select="$foo"/&gt;&lt;/href&gt;</div>
<br>
</li>
<li>
<div class="java-class">
&lt;href&gt;&lt;xsl:typed-value-of
select="$foo"/&gt;&lt;/href&gt;</div>
<br>
</li>
</ol>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>3.2</b></td>
<td colspan="1"><u class="p0">Must Support Sorting Nodes Based on XML
Schema Type</u> <br>
<p>XSLT 1.0 supports sorting based on <code>string</code>-valued and
<code>number</code>-valued expressions. <a
href="http://www.w3.org/TR/xmlschema-2/">XML Schema: Datatypes</a>
introduces new scalar types (for example, <code>date</code>) with
well-known sort orders. It MUST be possible to sort based on these
extended set of scalar data types. Since <a
href="http://www.w3.org/TR/xmlschema-2/">XML Schema: Datatypes</a>
does not define an ordering for complex types, this sorting support
should only be considered for simple types.</p>
<blockquote>
<p><b>Ed. Note: </b>Should be consistent with whatever we define for
the matrix of conversion and comparisons.</p>
</blockquote>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>3.3</b></td>
<td colspan="1"><u class="p2">Could Support Scientific Notation in
Number Formatting</u> <br>
<p>Several users have requested the ability to have the existing
<code>format-number()</code> function extended to format numbers using
Scientific Notation.</p>
</td>
</tr>
<tr class="r1">
<td colspan="1" valign="top">        </td>
<td colspan="1" valign="top" align="right"><b>3.4</b></td>
<td colspan="1"><u class="p2">Could Provide Ability to Detect Whether
"Rich" Schema Information is Available</u> <br>
<p>A stylesheet that requires XML Schema type-related functionality
COULD be able to test whether a "rich" Post-Schema-Validated Infoset
is available from the XML Schema processor, so that the stylesheet can
provide fallback behavior or choose to exit with <code>&lt;xsl:message
abort="yes"/&gt;</code>.</p>
</td>
</tr>
<tr class="r0">
<td colspan="1" valign="top" align="right"><b>4</b></td>
<td colspan="2"><u class="p0">Must Simplify Grouping</u> <br>
<p>Grouping is complicated in XSLT 1.0. It MUST be possible for users
to group nodes in a document based on</p>
<ul>
<li>common string-values</li>
<li>common names</li>
<li>common values for any other expression</li>
</ul>
<p>In addition XSLT must allow grouping based on sequential position,
e.g. selecting groups of adjacent <code>&lt;P&gt;</code> elements.
Ideally it should also make it easier to do fixed-size grouping as
well, e.g. groups of three adjacent nodes, for laying out data in
multiple columns. For each group of nodes identified, it must be
possible to instantiate a template for the group. Grouping must be
"nestable" to multiple levels so that groups of distinct nodes can be
identified, then from among the distinct groups selected, further
sub-grouping of distinct node in the current group can be done.</p>
<p>Often users express this requirement in different words, asking for
a way to easily select the distinct values of an XPath expression
relative to a nodeset. For example, many users using keys have
requested a function like <code>distinct-keys('</code> <i>keyname</i>
<code>')</code> to return a node-set containing, for each value of the
named key that is present in the current document, the first node in
document order that has that key value. Others have suggested adding a
<code>select-distinct="</code> <i>XpathExpression</i> <code>"</code>
to places where XSLT currently allows a <code>select</code>
attribute.</p>
<table border="0">
<tbody>
<tr>
<td colspan="1"><u><b>Use Case</b></u></td>
</tr>
<tr>
<td colspan="1"><ol>
<li><p><b>Group by common values, groups unsorted, with
group totals</b></p>
<p>Given XML document:</p>
<div class="java-class">
&lt;cities&gt;<br>
  &lt;city name="milan"  country="italy"  
pop="5"/&gt;<br>
  &lt;city
name="paris"  country="france"  pop="7"/&gt;<br>
  &lt;city name="munich" country="germany"
pop="4"/&gt;<br>
  &lt;city name="lyon"  
country="france"  pop="2"/&gt;<br>
  &lt;city name="venice" country="italy"  
pop="1"/&gt;<br>
&lt;/cities&gt;</div>
<br>
<p>Produce a 3-column table listing each distinct country
in the first column, an alphabetical list of the city
names for each country in the 2nd column, and the sum of
the population for the cities in each country in the third
column:</p>
<div class="java-class">
&lt;table&gt;<br>
  &lt;tr&gt;<br>
    &lt;th&gt;Country&lt;/th&gt;<br>
    &lt;th&gt;City List&lt;/th&gt;<br>
    &lt;th&gt;Population&lt;/th&gt;<br>
  &lt;/tr&gt;<br>
  &lt;tr&gt;<br>
    &lt;td&gt;italy&lt;/td&gt;<br>
    &lt;td&gt;milan, venice&lt;/td&gt;<br>
    &lt;td&gt;6&lt;/td&gt;<br>
  &lt;/tr&gt;<br>
  &lt;tr&gt;<br>
    &lt;td&gt;france&lt;/td&gt;<br>
    &lt;td&gt;lyon, paris&lt;/td&gt;<br>
    &lt;td&gt;9&lt;/td&gt;<br>
  &lt;/tr&gt;  <br>
  &lt;tr&gt;<br>
    &lt;td&gt;germany&lt;/td&gt;<br>
    &lt;td&gt;munich&lt;/td&gt;<br>
    &lt;td&gt;4&lt;/td&gt;<br>
  &lt;/tr&gt;  <br>
&lt;/table&gt;</div>
<br>
</li>
<li><p><b>Group by common values, sorting the groups, with
group totals</b></p>
<p>Given same XML document as in use case 1 above, produce
a 3-column table listing each distinct country in the
first column (sorted in alphabetical order), an
alphabetical list of the city names for each country in
the 2nd column, and the sum of the population for the
cities in each country in the third column:</p>
<div class="java-class">
&lt;table&gt;<br>
  &lt;tr&gt;<br>
    &lt;th&gt;Country&lt;/th&gt;<br>
    &lt;th&gt;City List&lt;/th&gt;<br>
    &lt;th&gt;Population&lt;/th&gt;<br>
  &lt;/tr&gt;<br>
  &lt;tr&gt;<br>
    &lt;td&gt;france&lt;/td&gt;<br>
    &lt;td&gt;lyon, paris&lt;/td&gt;<br>
    &lt;td&gt;9&lt;/td&gt;<br>
  &lt;/tr&gt;  <br>
  &lt;tr&gt;<br>
    &lt;td&gt;germany&lt;/td&gt;<br>
    &lt;td&gt;munich&lt;/td&gt;<br>
    &lt;td&gt;4&lt;/td&gt;<br>
  &lt;/tr&gt;  <br>
  &lt;tr&gt;<br>
    &lt;td&gt;italy&lt;/td&gt;<br>
    &lt;td&gt;milan, venice&lt;/td&gt;<br>
    &lt;td&gt;6&lt;/td&gt;<br>
  &lt;/tr&gt;<br>
&lt;/table&gt;</div>
<br>
</li>
<li><p><b>Group by common values, sorting the groups by a
group total</b></p>
<p>Given same XML document as in use case 1 above, produce
a 3-column table listing each distinct country in the
first column (sorted in order of decreasing total
population), a list of the city names for each country in
the 2nd column (sorted in order of decreasing population),
and the sum of the population for the cities in each
country in the third column:</p>
<div class="java-class">
&lt;table&gt;<br>
  &lt;tr&gt;<br>
    &lt;th&gt;Country&lt;/th&gt;<br>
    &lt;th&gt;City List&lt;/th&gt;<br>
    &lt;th&gt;Population&lt;/th&gt;<br>
  &lt;/tr&gt;<br>
  &lt;tr&gt;<br>
    &lt;td&gt;france&lt;/td&gt;<br>
    &lt;td&gt;paris, lyon&lt;/td&gt;<br>
    &lt;td&gt;9&lt;/td&gt;<br>
  &lt;/tr&gt;  <br>
  &lt;tr&gt;<br>
    &lt;td&gt;italy&lt;/td&gt;<br>
    &lt;td&gt;milan, venice&lt;/td&gt;<br>
    &lt;td&gt;6&lt;/td&gt;<br>
  &lt;/tr&gt;<br>
  &lt;tr&gt;<br>
    &lt;td&gt;germany&lt;/td&gt;<br>
    &lt;td&gt;munich&lt;/td&gt;<br>
    &lt;td&gt;4&lt;/td&gt;&lt;/tr&gt;  <br>
&lt;/table&gt;</div>
<br>
</li>
<li><p><b>Group by result of an expression (e.g. initial
letter, with a count for each group)</b></p>
<p>Given the input XML document above, produce the table
below which groups by the initial letter of the city name,
sorts these first-letters alphabetically, then produces a
list of cities whose names begin with that letter. The
heading contains a count of entries:</p>
<div class="java-class">
&lt;h2&gt;L (1)&lt;/h2&gt;&lt;p&gt;lyon&lt;/p&gt;<br>
&lt;h2&gt;M
(2)&lt;/h2&gt;&lt;p&gt;milan&lt;/p&gt;&lt;p&gt;munich&lt;/p&gt;<br>
&lt;h2&gt;P (1)&lt;/h2&gt;&lt;p&gt;paris&lt;/p&gt;<br>
&lt;h2&gt;V (1)&lt;/h2&gt;&lt;p&gt;venice&lt;/p&gt;</div>
<br>
</li>
<li><p><b>Group by patterns of elements in a
sequence</b></p>
<p>Given the input:</p>
<div class="java-class">
&lt;body&gt;<br>
  &lt;h2&gt;heading1&lt;/h2&gt;<br>
  &lt;p&gt;para1&lt;/p&gt;<br>
  &lt;p&gt;para2&lt;/p&gt;<br>
  &lt;h2&gt;heading2&lt;/h2&gt;<br>
  &lt;p&gt;para3&lt;/p&gt;<br>
  &lt;p&gt;para4&lt;/p&gt;<br>
  &lt;p&gt;para5&lt;/p&gt;<br>
&lt;/body&gt;</div>
<br>
<p>Produce the following output:</p>
<div class="java-class">
&lt;chapter&gt;<br>
  &lt;section title="heading1"&gt;<br>
    &lt;para&gt;para1&lt;/para&gt;<br>
    &lt;para&gt;para2&lt;/para&gt;<br>
  &lt;/section&gt; <br>
  &lt;section title="heading2"&gt;<br>
    &lt;para&gt;para3&lt;/para&gt;<br>
    &lt;para&gt;para4&lt;/para&gt;<br>
    &lt;para&gt;para5&lt;/para&gt;<br>
  &lt;/section&gt;<br>
&lt;/chapter&gt;</div>
<br>
</li>
<li><p><b>Produce Hierarchical Nested Output from Flat
Structure</b></p>
<p>Given a source document like:</p>
<div class="java-class">
&lt;doc&gt;<br>
  &lt;group1&gt;<br>
    &lt;tag&gt;value&lt;/tag&gt;<br>
  &lt;/group1&gt;<br>
  &lt;group2&gt;<br>
    &lt;tag&gt;value&lt;/tag&gt;<br>
  &lt;/group2&gt;<br>
  &lt;group2&gt;<br>
    &lt;tag&gt;value&lt;/tag&gt;<br>
  &lt;/group2&gt;<br>
  &lt;group3&gt;<br>
    &lt;tag&gt;value&lt;/tag&gt;<br>
  &lt;/group3&gt;<br>
&lt;/doc&gt;</div>
<br>
<p>produce the output:</p>
<div class="java-class">
&lt;doc&gt;<br>
  &lt;group1&gt;<br>
    &lt;tag&gt;value&lt;/tag&gt;<br>
    &lt;group2&gt;<br>
      &lt;tag&gt;value&lt;/tag&gt;<br>
    &lt;/group2&gt;</div>
<br>
<div class="java-class">
    &lt;group2&gt;<br>
      &lt;tag&gt;value&lt;/tag&gt;<br>
      &lt;group3&gt;<br>
        &lt;tag&gt;value&lt;/tag&gt;<br>
      &lt;/group3&gt;<br>
    &lt;/group2&gt;<br>
  &lt;/group1&gt;<br>
&lt;/doc&gt;</div>
<br>
</li>
<li><p><b>Formatting HTML Term Definition Lists (Case
1)</b></p>
<p>Given a source document like:</p>
<div class="java-class">
&lt;DL&gt;<br>
  &lt;!-- Handle the case with no DD or DT --&gt;<br>
  &lt;DT&gt;One&lt;/DT&gt;  <br>
  &lt;DD&gt;One Def&lt;/DD&gt;<br>
  &lt;DT&gt;Two&lt;/DT&gt;  <br>
  &lt;DD&gt;Two Def&lt;/DD&gt;<br>
  &lt;DT&gt;Three&lt;/DT&gt;  <br>
&lt;/DL&gt;</div>
<br>
<p>produce the output:</p>
<div class="java-class">
&lt;OL&gt;<br>
  &lt;LI&gt;&lt;B&gt;One&lt;B&gt; - &lt;I&gt;One
Def&lt;/I&gt;&lt;/LI&gt;<br>
  &lt;LI&gt;&lt;B&gt;Two&lt;B&gt; - &lt;I&gt;Two
Def&lt;/I&gt;&lt;/LI&gt;<br>
  &lt;LI&gt;&lt;B&gt;Three&lt;B&gt; - &lt;I&gt;(No
definition provided)&lt;/I&gt;&lt;/LI&gt;<br>
&lt;/OL&gt;</div>
<br>
</li>
<li><p><b>Formatting HTML Term Definition Lists (Case
2)</b></p>
<p>A slightly more compliated version of the HTML term
definition list involved multiple terms with a single
definition or multiple definitions for a single term.
Given the source</p>
<div class="java-class">
&lt;DL&gt;<br>
  &lt;DT&gt;One&lt;/DT&gt;<br>
  &lt;DT&gt;Two&lt;/DT&gt;<br>
  &lt;DD&gt;One and Two Def&lt;/DD&gt;<br>
&lt;/DL&gt;</div>
<br>
<p>produce the output</p>
<div class="java-class">
&lt;OL&gt;<br>
  &lt;LI&gt;&lt;B&gt;One, Two&lt;/B&gt; - &lt;I&gt;One and
Two Def&lt;/I&gt;&lt;/LI&gt;<br>
&lt;/OL&gt;</div>
<br>
<p>For the other varation, given the source:</p>
<div class="java-class">
&lt;DL&gt;<br>
  &lt;DT&gt;One&lt;/DT&gt;<br>
  &lt;DD&gt;One Def&lt;/DD&gt;<br>
  &lt;DD&gt;Another One Def&lt;/DD&gt;<br>
&lt;/DL&gt;</div>
<br>
<p>produce the output:</p>
<div class="java-class">
&lt;UL&gt;<br>
  &lt;LI&gt;<br>
    &lt;B&gt;One&lt;/B&gt;<br>
    &lt;OL&gt;<br>
      &lt;LI&gt;One Def&lt;/LI&gt;<br>
      &lt;LI&gt;Another One Def&lt;/LI&gt;<br>
    &lt;/OL&gt;<br>
  &lt;/LI&gt;<br>
&lt;/UL&gt;</div>
<br>
</li>
<li><p><b>Transform Inline &lt;para&gt; Elements to Block
&lt;para&gt; Elements</b></p>
<p>Transform from a DTD that allows para elements to have
nested block-level elements to a DTD that requires para
elements to have only inline elements, e.g. transform:</p>
<div class="java-class">
&lt;p&gt;Do &lt;em&gt;not&lt;/em&gt;:<br>
&lt;ul&gt;<br>
&lt;li&gt;talk,&lt;/li&gt;<br>
&lt;li&gt;eat, or&lt;/li&gt;<br>
&lt;li&gt;use your mobile telephone&lt;/li&gt;<br>
&lt;/ul&gt;<br>
while you are in the cinema.&lt;/p&gt;</div>
<br>
<p>into:</p>
<div class="java-class">
&lt;p&gt;Do &lt;em&gt;not&lt;/em&gt;:&lt;/p&gt;<br>
&lt;ul&gt;<br>
&lt;li&gt;talk,&lt;/li&gt;<br>
&lt;li&gt;eat, or&lt;/li&gt;<br>
&lt;li&gt;use your mobile telephone&lt;/li&gt;<br>
&lt;/ul&gt;<br>
&lt;p&gt;while you are in the cinema.&lt;/p&gt;</div>
<br>
</li>
<li><p><b>Arrange into Fixed-Sized Groups
(Across/Down)</b></p>
<p>Given the input from use case number 1 above, produce a
two-column list of all city names, sorted alphabetically,
in "Across/Down" format. The result should correctly
format the "left over" cells when the number of items is
not a multiple of the number of items in the group.</p>
<div class="java-class">
&lt;table&gt;<br>
  &lt;!-- Alphabetized Across each row --&gt;<br>
  &lt;tr&gt;&lt;td&gt;lyon&lt;/td&gt;&lt;td&gt;milan&lt;/td&gt;&lt;/tr&gt;<br>
  &lt;tr&gt;&lt;td&gt;munich&lt;/td&gt;&lt;td&gt;paris&lt;/td&gt;&lt;/tr&gt;<br>
  &lt;tr&gt;&lt;td&gt;venice&lt;/td&gt;&lt;td&gt;&amp;nbsp;&lt;/td&gt;&lt;/tr&gt;<br>
&lt;/table&gt;<br>
</div>
<br>
</li>
<li><p><b>Arrange into Fixed-Sized Groups
(Down/Across)</b></p>
<p>Given the input from use case number 1 above, produce a
two-column list of all city names, sorted alphabetically,
in "Down/Across" format. The result should correctly
format the "left over" cells when the number of items is
not a multiple of the number of items in the group.</p>
<div class="java-class">
&lt;table&gt;<br>
  &lt;!-- Alphabetized Down each column --&gt;<br>
  &lt;tr&gt;&lt;td&gt;lyon&lt;/td&gt;&lt;td&gt;paris&lt;/td&gt;&lt;/tr&gt;<br>
  &lt;tr&gt;&lt;td&gt;milan&lt;/td&gt;&lt;td&gt;venice&lt;/td&gt;&lt;/tr&gt;<br>
  &lt;tr&gt;&lt;td&gt;munich&lt;/td&gt;&lt;td&gt;&amp;nbsp;&lt;/td&gt;&lt;/tr&gt;<br>
&lt;/table&gt;<br>
</div>
<br>
</li>
<li><p><b>Multi-level Grouping</b></p>
<p>Given the XML list of software bugs assigned to
developers on different teams...</p>
<div class="java-class">
&lt;bugs&gt;<br>
  &lt;bug dev="ace" team="ui"&gt;<br>
    &lt;desc&gt;Border shows white when it should be
grey&lt;/desc&gt;<br>
  &lt;/bug&gt;<br>
  &lt;bug dev="tom" team="core"&gt;<br>
    &lt;desc&gt;Incorrectly handling nulls on
entry&lt;/desc&gt;<br>
  &lt;/bug&gt;<br>
  &lt;bug dev="gary" team="ui"&gt;<br>
    &lt;desc&gt;Preferences dialog has two Cancel
buttons&lt;/desc&gt;<br>
  &lt;/bug&gt;<br>
  &lt;bug dev="ace" team="ui"&gt;<br>
    &lt;desc&gt;Drag and drop cursor never changes
back&lt;/desc&gt;<br>
  &lt;/bug&gt;<br>
  &lt;bug dev="tim" team="core"&gt;<br>
    &lt;desc&gt;Infinite loop in validation
code&lt;/desc&gt;<br>
  &lt;/bug&gt;<br>
  &lt;bug dev="gary" team="ui"&gt;<br>
    &lt;desc&gt;Resizing dialog doesn't resize text
box&lt;/desc&gt;<br>
  &lt;/bug&gt;<br>
  &lt;bug dev="ace" team="ui"&gt;<br>
    &lt;desc&gt;German text is truncated&lt;/desc&gt;<br>
  &lt;/bug&gt;<br>
  &lt;bug dev="tim" team="core"&gt;<br>
    &lt;desc&gt;Data inserted twice&lt;/desc&gt;<br>
  &lt;/bug&gt;<br>
&lt;/bugs&gt;<br>
</div>
<br>
<p>produce an HTML page that includes:</p>
<ul>
<li>The total number of open bugs in the title</li>
<li>A column for each team of developers, with a
per-team bug count. The teams should be ordered left
to right by descreasing number of open bugs assigned
to the team.</li>
<li>A vertical list (separated by &lt;br/&gt; tags) of
developers on each team, with their bug count.
Developers should be listed top down in order of
descreasing individual bug count.</li>
</ul>
<p>The result is a nested, grouped output giving
development managers a bird's-eye view of which teams and
which developers are in the most "bug trouble":</p>
<div class="java-class">
&lt;html&gt;<br>
  &lt;body&gt;<br>
    &lt;h2&gt;Bug Summary (8)&lt;/h2&gt;<br>
    &lt;table&gt;<br>
      &lt;tr&gt;<br>
       &lt;th&gt;ui (5)&lt;/th&gt;<br>
       &lt;th&gt;core (3)&lt;/th&gt;<br>
      &lt;/tr&gt;<br>
      &lt;tr&gt;<br>
       &lt;td&gt;<br>
         ace (3)&lt;br/&gt;<br>
         gary (2)<br>
       &lt;/td&gt;<br>
       &lt;td&gt;<br>
         tim (2)&lt;br/&gt;<br>
         tom (1)<br>
       &lt;/td&gt;<br>
      &lt;/tr&gt;<br>
    &lt;/table&gt;<br>
  &lt;/body&gt;<br>
&lt;/html&gt;</div>
<br>
</li>
<li><p>List all the different element names in a document,
and for each one list all the attributes used, and for
each attribute list the distinct values used in the
document. For example, given the document:</p>
<div class="java-class">
&lt;foo baz="Q"&gt;<br>
  &lt;bar baz="3" bop="T"/&gt;<br>
  &lt;foo baz="1"&gt;<br>
    &lt;bar bop="S" bip="4" baz="5"/&gt;<br>
  &lt;/foo&gt;<br>
&lt;/foo&gt;</div>
<br>
<p>Produce the result:</p>
<div class="java-class">
&lt;inventory&gt;<br>
  &lt;element name="bar"&gt;<br>
    &lt;attribute name="baz"&gt;<br>
      &lt;value&gt;3&lt;/value&gt;<br>
      &lt;value&gt;5&lt;/value&gt;<br>
    &lt;/attribute&gt;<br>
    &lt;attribute name="bip"&gt;<br>
      &lt;value&gt;4&lt;/value&gt;<br>
    &lt;/attribute&gt;<br>
    &lt;attribute name="bop"&gt;<br>
      &lt;value&gt;S&lt;/value&gt;<br>
      &lt;value&gt;T&lt;/value&gt;<br>
    &lt;/attribute&gt;<br>
  &lt;/element&gt;<br>
  &lt;element name="foo"&gt;<br>
    &lt;attribute name="baz"&gt;<br>
      &lt;value&gt;1&lt;/value&gt;<br>
      &lt;value&gt;Q&lt;/value&gt;<br>
    &lt;/attribute&gt;<br>
  &lt;/element&gt;<br>
&lt;/inventory&gt;</div>
<br>
</li>
</ol>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<h2><a name="section-References"></a>3 References</h2>
<dl>
<dt></dt>
<dd>XML Schema: Structures, <a
href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1/</a></dd>
<dt></dt>
<dd>XML Schema: Datatypes, <a
href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2/</a></dd>
</dl>
</body>
</html>