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.

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

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

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.

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

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.

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

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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:

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.

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

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

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

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.

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.

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.

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.

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.

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.

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

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"/>.

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

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.