XSL Tree Construction Issues

issue-any-node-type

Should there be a pattern that matches any type of node, or any type of child node?

issue-attribute-qual-case

Do we need to be able to match attributes in a case insensitive way?

issue-attribute-set

Merging is the only functionality offered by attribute sets that is not provided by macros. Is this a sufficient reason to keep attribute sets?

issue-attribute-value-template-where

Which attribute values should be interpreted as attribute value templates?

issue-class-attribute

Should there be a way of specifying that an attribute serves as a class attribute and then pattern syntax that treats class attributes specially?

issue-condition-test

What should be the name and allowed value of the attribute that specifies the condition on xsl:if and xsl:when? Should it be generalized to allow anything that is allowed within []? Should it be a match pattern rather than a select pattern?

issue-constant-syntax

The syntax of constant() seems inconsistent with id() and pi(). Either constant("foo") or something like $foo would be consistent. Should it be changed? The same issue arises with arg().

issue-constant-value

Should the value of the constant be specified in the content of the xsl:constant element rather than by a value attribute?

issue-construct-extensibility

Should there be some extensibility mechanism for the tree construction process? If so, how should it work? Should it be language independent?

issue-data-entity

Should XSL provide support for external data entities and notations?

issue-declare-multiple-elements

Should the value of the element attribute of xsl:strip-space, xsl:preserve-space and xsl:id be a list of element type names (and thus be renamed to elements)? If so, should the attribute attribute of xsl:id also be a list of attribute names?

issue-default-priority

Should there be a more complicated way of calculating the default priority? For example, -1 for *, 0 for just an element type name, and 1 for more complex patterns.

issue-entity-ref

Should XSL provide support for entity references?

issue-expressions

Should be provide a more general expression capability supporting arithmetic and string manipulation? Should expressions be integrated into the pattern language? This is also related to the condition-test issue.

issue-external-dtd

Should we specify something about how we expect XSL processors to process external DTDs and parameter entities? For example, what happens if an attribute default is declared in an external DTD?

issue-for-each-select-default

Should the select attribute default in the same way as with xsl:apply-templates?

issue-group-position

Do we need first-of-group() and last-of-group() that tests whether the element is first or last in a group of consecutive elements of the same element type?

issue-group-siblings

A model in which templates are applied to each node separately and the results always simply concatenated does not handle the case where sequences of siblings need to be grouped into an containing element, for example, transforming <dl><dt/><dd/><dt/><dd/></dl> to <dl><di><dt/><dd/></di><di><dt/><dd/></di></dl>. How can this problem be solved?

issue-id-inverse

Should there be a way to get back from a element to the elements that reference it (eg by IDREF attributes)?

issue-id-middle

Should id() be disallowed after /? This loses no functionality since foo/id(@bar) is equivalent to id(foo/@bar).

issue-id-name

Should id() be renamed to something less confusing like element-with-id()?

issue-if-when-unify

Should xsl:if and xsl:when be unified into a single element?

issue-import-media

Should we provide media-dependent imports as in CSS?

issue-import-source

Provide a way for a stylesheet to import a stylesheet that is embedded in the document.

issue-instruction-error

Should there be an instruction that generates an error, like the error procedure in DSSSL?

issue-local-constants

Should there be a way to define local constants?

issue-macro-arg-syntax

The proposal used the same element for declaring macro arguments and for invoking them. Should these be separate elements and if so what should they be called?

issue-macro-name

Should macros be called something else?

issue-match-initial-word

In CSS2, [att|=val] matches when when the element's att attribute value is a hyphen-separated list of "words", beginning with val. This is useful with xml:lang. How should this be provided in XSL?

issue-match-lang

CSS2 has a :lang pseudo-class for convenient matching on the language of an element. This deals with inheritance, language subcodes, and case-insensitivity. How should this functionality be provided in XSL?

issue-match-token

In CSS2, [att~=val] matches when when the element's att attribute value is a space-separated list of "words", one of which is exactly val. How should this functionality be provided in XSL?

issue-media-rule

Should we provide the functionality of CSS's @media rule and if so how?

issue-multiple-results

Should it be possible to create multiple result trees?

issue-multiple-sources

Should it be possible for patterns to select nodes in documents other than the source document?

issue-name-parts

How can the namespace and local part be accessed separately? This would be necessary to, for example, provide a "View Source" stylesheet.

issue-pattern-namespace-wildcards

Should patterns of the form foo:* or *:foo be allowed? If so, should * match any element or any element without a namespace URI?

issue-positional-qual

Positional qualifiers don't allow users to specify different handling based on the position of a node in a sorted node list resulting from the use of xsl:sort? The also are confusingly named. How should they be fixed?

issue-regex

Should XSL support regular expressions for matching against any or all of pcdata content, attribute values, attribute names, element type names?

issue-resolve-expr

Do we need a resolve(pattern) string expression that treats the characters as a relative URI and turns it into an absolute URI using the base URI of the addressed node?

issue-restrict-match-pattern

Use of id() with a select pattern argument is hard to implement and confusing in match patterns. Should it be disallowed? Should ancestor(), .. and . also be disallowed?

issue-sibling-qual

Should there be qualifiers that constrain an element to have an immediately preceding or following sibling of a particular type?

issue-template-match-default

Should the match attribute have a default? Any node? Any child node? The root node?

issue-unique-id-content

Should it be possible for a unique id to be specified in the content of an element instead of in an attribute?

issue-value-of-select-default

Should the select attribute have a default value of .?

issue-versioning

Should there be some way for a stylesheet to indicate which version of XSL it conforms to? Can this be done through the URI of the XSL namespace?

issue-xpointer

Should there be support for following XPointers as well as IDs?