CARVIEW

MOTORHOMES

Select Language

HTTP/2 302 server: nginx date: Sun, 03 Aug 2025 10:47:34 GMT content-type: text/plain; charset=utf-8 content-length: 0 x-archive-redirect-reason: found capture at 20151130015938 location: https://web.archive.org/web/20151130015938/https://www.w3.org/TR/xslt20req server-timing: captures_list;dur=0.645461, exclusion.robots;dur=0.024204, exclusion.robots.policy;dur=0.010828, esindex;dur=0.012694, cdx.remote;dur=29.536964, LoadShardBlock;dur=247.757870, PetaboxLoader3.datanode;dur=112.755847, PetaboxLoader3.resolve;dur=113.875200 x-app-server: wwwb-app212 x-ts: 302 x-tr: 314 server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0 set-cookie: wb-p-SERVER=wwwb-app212; path=/ x-location: All x-rl: 0 x-na: 0 x-page-cache: MISS server-timing: MISS x-nid: DigitalOcean referrer-policy: no-referrer-when-downgrade permissions-policy: interest-cohort=() HTTP/2 200 server: nginx date: Sun, 03 Aug 2025 10:47:35 GMT content-type: text/html; charset=iso-8859-1 x-archive-orig-date: Mon, 30 Nov 2015 01:59:38 GMT x-archive-orig-server: Apache/2 content-location: xslt20req.html x-archive-orig-vary: negotiate x-archive-orig-tcn: choice x-archive-orig-last-modified: Fri, 16 Feb 2001 00:23:50 GMT x-archive-orig-etag: "e865-37d6197127180;5256f23d08480" x-archive-orig-accept-ranges: bytes x-archive-orig-content-length: 59493 x-archive-orig-cache-control: max-age=21600 x-archive-orig-expires: Mon, 30 Nov 2015 07:59:38 GMT x-archive-orig-p3p: policyref="https://www.w3.org/2014/08/p3p.xml" x-archive-orig-access-control-allow-origin: * x-archive-orig-connection: close x-archive-guessed-content-type: text/html x-archive-guessed-charset: iso-8859-15 memento-datetime: Mon, 30 Nov 2015 01:59:38 GMT link: ; rel="original", ; rel="timemap"; type="application/link-format", ; rel="timegate", ; rel="first memento"; datetime="Fri, 09 Mar 2001 02:30:33 GMT", ; rel="prev memento"; datetime="Thu, 29 Oct 2015 18:03:55 GMT", ; rel="memento"; datetime="Mon, 30 Nov 2015 01:59:38 GMT", ; rel="next memento"; datetime="Tue, 15 Mar 2016 21:09:28 GMT", ; rel="last memento"; datetime="Fri, 20 Jun 2025 10:24:16 GMT" content-security-policy: default-src 'self' 'unsafe-eval' 'unsafe-inline' data: blob: archive.org web.archive.org web-static.archive.org wayback-api.archive.org athena.archive.org analytics.archive.org pragma.archivelab.org wwwb-events.archive.org x-archive-src: alexa20151130-15/51_49_20151130015912_crawl301.arc.gz server-timing: captures_list;dur=0.533373, exclusion.robots;dur=0.020291, exclusion.robots.policy;dur=0.009778, esindex;dur=0.012657, cdx.remote;dur=96.446458, LoadShardBlock;dur=571.188193, PetaboxLoader3.resolve;dur=459.671843, PetaboxLoader3.datanode;dur=143.353797, load_resource;dur=191.643015 x-app-server: wwwb-app212 x-ts: 200 x-tr: 934 server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0 x-location: All x-rl: 0 x-na: 0 x-page-cache: MISS server-timing: MISS x-nid: DigitalOcean referrer-policy: no-referrer-when-downgrade permissions-policy: interest-cohort=() content-encoding: gzip XSLT Requirements

XSLT Requirements
Version 2.0

W3C Working Draft 14 February 2001

This version:: https://www.w3.org/TR/2001/WD-xslt20req-20010214
(available in XML or HTML)
Latest version:: https://www.w3.org/TR/xslt20req
Editors:: Steve Muench (Oracle) <Steve.Muench@oracle.com>
Mark Scardina (Oracle) <Mark.Scardina@oracle.com>

Abstract

This document describes the requirements for the XSLT 2.0 specification.

Status of this document

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.

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

This document has been produced as part of the W3C Style activity, following the procedures set out for the W3C Process. The document has been written by the XSL Working Group (W3C members only). The goals of the XSL Working Group are discussed in the XSL Working Group charter. The XSL Working Group feels that the contents of this Working Draft are relatively stable, and therefore encourages feedback on this version.

Comments on this document should be sent to the W3C mailing list xsl-editors@w3.org (archived at https://lists.w3.org/Archives/Public/xsl-editors/). A list of current W3C Recommendations and other technical documents can be found at https://www.w3.org/TR/.

1 Goals
2 Requirements
3 References

Appendices

1 Goals

XSLT 2.0 has the following goals:

Simplify manipulation of XML Schema-typed content
Simplify manipulation of string content
Support related XML standards
Improve ease of use
Improve interoperability
Improve i18n support
Maintain backward compatibility
Enable improved processor efficiency

In addition, the following are explicitly not goals:

Simplifying the ability to parse unstructured information to produce structured results.
Turning XSLT into a general-purpose programming language

2 Requirements

Must?Support the XML "Family" of Standards

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.

????????

1.1

Must?Maintain Backwards Compatibility with XSLT 1.1

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

????????

1.2

Must?Match Elements with Null Values

A stylesheet SHOULD be able to match elements and attributes whose value is explicitly null.

Ed. Note: Just matching @xsi:null="true" would find elements with this attribute even if the element actually had content like:

<foo xsi:null="true">SomeValue</foo>

or used the xsi:null when the element did not allow its content to be nullable, both of which are invalid.

????????

1.3

Should?Allow Included Documents to "Encapsulate" Local Stylesheets

XSLT 2.0 SHOULD define a mechanism to allow the templates in a stylesheet associated with a secondary source document, to be imported and used to format the included fragment, taking precedence over any applicable templates in the current stylesheet.

Use Case

When a MATHML document is included in the current source document, that MATHML fragment could already contain its own <?xml-stylesheet?> indicating appropriate templates to properly style the Math.

????????

1.4

Could?Support Accessing Infoset Items for XML Declaration

A stylesheet COULD be able to access information like the version and encoding from the XML declaration of a document.

Use Case

A stylesheet should be able to set the output encoding to use the same encoding as the input document.

????????

1.5

Could?Provide QName Aware String Functions

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.

????????

1.6

Could?Enable Constructing a Namespace with Computed Name

Provide an <xsl:namespace> analog to <xsl:element> for constructing a namespace node with a computed prefix and URI.

????????

1.7

Could?Simplify Resolving Prefix Conflicts in QName-Valued Attributes

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.

????????

1.8

Could?Support XHTML Output Method

Complementing the existing output methods for html, xml, and text, an xhtml output method could be provided to simplify transformations which target XHTML output.

Must?Improve Ease of Use

XSLT 2.0 MUST address frequently requested enhancements to make using XPath even more straightfoward for handling common use cases.

????????

2.1

Must?Allow Matching on Default Namespace Without Explicit Prefix

Many users stumble trying to match an element with a default namespace. They expect to be able to do something like:

<xsl:stylesheet version="1.0"
???????? xmlns:xsl="https://www.w3.org/1999/XSL/Transform"
???????? xmlns="urn:myuri">
??
??<xsl:template match="foo">

thinking that leaving off the prefix from the foo element name, that it will match <foo> elements in the default namespace with the URI of urn:myuri. Instead, they are required to assign a non-null prefix name to their namespace URI and then match on "someprefix:foo" 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.

????????

2.2

Must?Add Date Formatting Functions

One of the more frequent requests from XSLT 1.0 users is the ability to format date information with similar control to XSLT's format-number(). 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 java.text.SimpleDateFormat. A date analog of XSLT's named xsl:decimal-format may be required to handle locale-specific date formatting issues.

Use Case

Given an XML element like: <Period start="2000-05-07" end="2000-05-13"/>

Format it as: Invoice: 7 May 2000 - 13 May 2000
Given the same element above, format it according to the current locale as:

Fattura: 7 Maggio 2000 - 13 Maggio 2000

????????

2.3

Must?Simplify Accessing Id's and Key's in Other Documents

Currently it is cumbersome to lookup nodes by id() or key() in documents other than the source document. Users must first use an xsl:for-each instruction, selecting the desired document() to make it the current node, then relative XPath expressions within the scope of the xsl:for-each can refer to id() or key() as desired.

????????

2.4

Should?Provide Function to Absolutize Relative URIs

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.

????????

2.5

Should?Include Unparsed Text from an External Resource

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 document() function which, while useful, can only read external resources that are well-formed XML documents.

Use Case

Given an XML document like:

<section>
??<para>The code for the example looks like this:</para>
??<example>
????<external-file href="ParseXML.java"/>
??</example>
</section>

Format the section and include the source of the sample code from the external file in the output.

????????

2.6

Should?Allow Authoring Extension Functions in XSLT

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.

????????

2.7

Should?Output Character Entity References Instead of Numeric Character Entities

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   in the output, the user could request to see the equivalent   instead.

????????

2.8

Should?Construct Entity Reference by Name

Analogous to the ability to create elements and attributes, users have expressed a desire to construct named entity references.

Ed. Note: Does this require a change to the data model?

????????

2.9

Should?Support for Unicode String Normalization

For reliable string comparison of Unicode strings, users need the ability to apply Unicode normalization before comparing the strings.

????????

2.10

Should?Standardize Extension Element Language Bindings

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.

????????

2.11

Could?Improve Efficiency of Transformations on Large Documents

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:

Identifying a core subset of XPath that does not require random access to the source tree, or
Consider a "transform all subtrees" mode where the stylesheet says, "Apply the transformation implied by this stylesheet to each node that matches XXX, 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."

Use Case

Transforming an XML document representing the daily closing prices of NASDAQ stocks for 1999 like the example below (over 1.3 millon <ClosingQuote> sub-elements) to produce a comma-separated list of Ticker, Date, and Closing Price.

????????

2.12

Could?Support for Reverse IDREF attributes

Given a particular value of an ID, produce a list of all elements that have an IDREF or IDREFS attribute which refers to this ID.

Ed. Note: This functionality can be accomplished using the current <xsl:key> and key() mechanism.

????????

2.13

Could?Support for Case-Insensitive Comparisons

XSLT 2.0 could expand its comparison functionality to include support for case-insensitive string comparison.

????????

2.14

Could?Support Lexigraphic String Comparisons

We don't let users compare strings like $x > 'a'.

Ed. Note: i18n issues.

????????

2.15

Could?Allow Comparing Nodes Based on Document Order

Support the ability to test whether one node comes before another in document order.

Ed. Note: Need a Use Case for this.

????????

2.16

Could?Improve Support for Unparsed Entities

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.

????????

2.17

Could?Allow Processing a Node with the "Next Best Matching" Template

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 <xsl:apply-templates/> specifies that for any given node only a single template will be selected and instantiated.

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 <xsl:next-match/>, 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.

Use Case

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 diff for marking changes made between one version of a document and another. You must now augment your stylesheet to support this new behavior.

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:

<xsl:template match="*[@diff='new']">
??<div class="new">
????
??</div>
</xsl:template>

<xsl:template match="para">
??<p>
????<xsl:apply-templates/>
??</p>
</xsl:template>

When passed a document that contains <p diff='new'>...</p>, it would produce:

????????

2.18

Could?Make Coercions Symmetric By Allowing Scalar to Nodeset Conversion

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.

Must?Support XML Schema

XML Schema: Structures and XML Schema: Datatypes 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.

????????

3.1

Must?Simplify Constructing and Copying Typed Content

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.

Ed. Note: Use Case needs work.

Use Case

<href xsi:type="urireference">foo.xml</href>
<href xsl:type="urireference"><xsl:value-of select="$foo"/></href>
<href><xsl:typed-value-of select="$foo"/></href>

????????

3.2

Must?Support Sorting Nodes Based on XML Schema Type

XSLT 1.0 supports sorting based on string-valued and number-valued expressions. XML Schema: Datatypes introduces new scalar types (for example, date) with well-known sort orders. It MUST be possible to sort based on these extended set of scalar data types. Since XML Schema: Datatypes does not define an ordering for complex types, this sorting support should only be considered for simple types.

Ed. Note: Should be consistent with whatever we define for the matrix of conversion and comparisons.

????????

3.3

Could?Support Scientific Notation in Number Formatting

Several users have requested the ability to have the existing format-number() function extended to format numbers using Scientific Notation.

????????

3.4

Could?Provide Ability to Detect Whether "Rich" Schema Information is Available

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 <xsl:message abort="yes"/>.

Must?Simplify Grouping

Grouping is complicated in XSLT 1.0. It MUST be possible for users to group nodes in a document based on

common string-values
common names
common values for any other expression

In addition XSLT must allow grouping based on sequential position, e.g. selecting groups of adjacent <P> 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.

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 distinct-keys(' keyname ') 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 select-distinct=" XpathExpression " to places where XSLT currently allows a select attribute.

Use Case

Group by common values, groups unsorted, with group totals

Given XML document:

<cities>
??<city name="milan"??country="italy"?? pop="5"/>
??<city name="paris"??country="france"??pop="7"/>
??<city name="munich" country="germany" pop="4"/>
??<city name="lyon"?? country="france"??pop="2"/>
??<city name="venice" country="italy"?? pop="1"/>
</cities>

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:

<table>
??<tr>
????<th>Country</th>
????<th>City List</th>
????<th>Population</th>
??</tr>
??<tr>
????<td>italy</td>
????<td>milan, venice</td>
????<td>6</td>
??</tr>
??<tr>
????<td>france</td>
????<td>lyon, paris</td>
????<td>9</td>
??</tr>??
??<tr>
????<td>germany</td>
????<td>munich</td>
????<td>4</td>
??</tr>??
</table>
Group by common values, sorting the groups, with group totals

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:

<table>
??<tr>
????<th>Country</th>
????<th>City List</th>
????<th>Population</th>
??</tr>
??<tr>
????<td>france</td>
????<td>lyon, paris</td>
????<td>9</td>
??</tr>??
??<tr>
????<td>germany</td>
????<td>munich</td>
????<td>4</td>
??</tr>??
??<tr>
????<td>italy</td>
????<td>milan, venice</td>
????<td>6</td>
??</tr>
</table>
Group by common values, sorting the groups by a group total

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:

<table>
??<tr>
????<th>Country</th>
????<th>City List</th>
????<th>Population</th>
??</tr>
??<tr>
????<td>france</td>
????<td>paris, lyon</td>
????<td>9</td>
??</tr>??
??<tr>
????<td>italy</td>
????<td>milan, venice</td>
????<td>6</td>
??</tr>
??<tr>
????<td>germany</td>
????<td>munich</td>
????<td>4</td></tr>??
</table>
Group by result of an expression (e.g. initial letter, with a count for each group)

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:

<h2>L (1)</h2><p>lyon</p>
<h2>M (2)</h2><p>milan</p><p>munich</p>
<h2>P (1)</h2><p>paris</p>
<h2>V (1)</h2><p>venice</p>
Group by patterns of elements in a sequence

Given the input:

<body>
??<h2>heading1</h2>
??<p>para1</p>
??<p>para2</p>
??<h2>heading2</h2>
??<p>para3</p>
??<p>para4</p>
??<p>para5</p>
</body>

Produce the following output:

<chapter>
??<section title="heading1">
????<para>para1</para>
????<para>para2</para>
??</section>
??<section title="heading2">
????<para>para3</para>
????<para>para4</para>
????<para>para5</para>
??</section>
</chapter>
Produce Hierarchical Nested Output from Flat Structure

Given a source document like:

<doc>
??<group1>
????<tag>value</tag>
??</group1>
??<group2>
????<tag>value</tag>
??</group2>
??<group2>
????<tag>value</tag>
??</group2>
??<group3>
????<tag>value</tag>
??</group3>
</doc>

produce the output:

<doc>
??<group1>
????<tag>value</tag>
????<group2>
??????<tag>value</tag>
????</group2>

????<group2>
??????<tag>value</tag>
??????<group3>
????????<tag>value</tag>
??????</group3>
????</group2>
??</group1>
</doc>
Formatting HTML Term Definition Lists (Case 1)

Given a source document like:

<DL>
??
??<DT>One</DT>??
??<DD>One Def</DD>
??<DT>Two</DT>??
??<DD>Two Def</DD>
??<DT>Three</DT>??
</DL>

produce the output:

<OL>
??<LI><B>One<B> - <I>One Def</I></LI>
??<LI><B>Two<B> - <I>Two Def</I></LI>
??<LI><B>Three<B> - <I>(No definition provided)</I></LI>
</OL>
Formatting HTML Term Definition Lists (Case 2)

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

<DL>
??<DT>One</DT>
??<DT>Two</DT>
??<DD>One and Two Def</DD>
</DL>

produce the output

<OL>
??<LI><B>One, Two</B> - <I>One and Two Def</I></LI>
</OL>

For the other varation, given the source:

<DL>
??<DT>One</DT>
??<DD>One Def</DD>
??<DD>Another One Def</DD>
</DL>

produce the output:

<UL>
??<LI>
????<B>One</B>
????<OL>
??????<LI>One Def</LI>
??????<LI>Another One Def</LI>
????</OL>
??</LI>
</UL>
Transform Inline <para> Elements to Block <para> Elements

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>Do <em>not</em>:
<ul>
<li>talk,</li>
<li>eat, or</li>
<li>use your mobile telephone</li>
</ul>
while you are in the cinema.</p>

into:

<p>Do <em>not</em>:</p>
<ul>
<li>talk,</li>
<li>eat, or</li>
<li>use your mobile telephone</li>
</ul>
<p>while you are in the cinema.</p>
Arrange into Fixed-Sized Groups (Across/Down)

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.

<table>
??
??<tr><td>lyon</td><td>milan</td></tr>
??<tr><td>munich</td><td>paris</td></tr>
??<tr><td>venice</td><td> </td></tr>
</table>
Arrange into Fixed-Sized Groups (Down/Across)

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.

<table>
??
??<tr><td>lyon</td><td>paris</td></tr>
??<tr><td>milan</td><td>venice</td></tr>
??<tr><td>munich</td><td> </td></tr>
</table>
Multi-level Grouping

Given the XML list of software bugs assigned to developers on different teams...

<bugs>
??<bug dev="ace" team="ui">
????<desc>Border shows white when it should be grey</desc>
??</bug>
??<bug dev="tom" team="core">
????<desc>Incorrectly handling nulls on entry</desc>
??</bug>
??<bug dev="gary" team="ui">
????<desc>Preferences dialog has two Cancel buttons</desc>
??</bug>
??<bug dev="ace" team="ui">
????<desc>Drag and drop cursor never changes back</desc>
??</bug>
??<bug dev="tim" team="core">
????<desc>Infinite loop in validation code</desc>
??</bug>
??<bug dev="gary" team="ui">
????<desc>Resizing dialog doesn't resize text box</desc>
??</bug>
??<bug dev="ace" team="ui">
????<desc>German text is truncated</desc>
??</bug>
??<bug dev="tim" team="core">
????<desc>Data inserted twice</desc>
??</bug>
</bugs>

produce an HTML page that includes:
- The total number of open bugs in the title
- 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.
- A vertical list (separated by <br/> tags) of developers on each team, with their bug count. Developers should be listed top down in order of descreasing individual bug count.
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":

<html>
??<body>
????<h2>Bug Summary (8)</h2>
????<table>
??????<tr>
?????? <th>ui (5)</th>
???? ??<th>core (3)</th>
??????</tr>
??????<tr>
???? ??<td>
???? ????ace (3)<br/>
???? ????gary (2)
???? ??</td>
???? ??<td>
???? ????tim (2)<br/>
???? ????tom (1)
???? ??</td>
??????</tr>
????</table>
??</body>
</html>
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:

<foo baz="Q">
??<bar baz="3" bop="T"/>
??<foo baz="1">
????<bar bop="S" bip="4" baz="5"/>
??</foo>
</foo>

Produce the result:

<inventory>
??<element name="bar">
????<attribute name="baz">
??????<value>3</value>
??????<value>5</value>
????</attribute>
????<attribute name="bip">
??????<value>4</value>
????</attribute>
????<attribute name="bop">
??????<value>S</value>
??????<value>T</value>
????</attribute>
??</element>
??<element name="foo">
????<attribute name="baz">
??????<value>1</value>
??????<value>Q</value>
????</attribute>
??</element>
</inventory>

3 References

: XML Schema: Structures, https://www.w3.org/TR/xmlschema-1/
: XML Schema: Datatypes, https://www.w3.org/TR/xmlschema-2/

Original Source | Taken Source

XSLT Requirements Version 2.0

W3C Working Draft 14 February 2001

Abstract

Status of this document

Table of contents

Appendices

1 Goals

2 Requirements

3 References

XSLT Requirements
Version 2.0