Should there be a pattern that matches any type of node, or any type of child node?
Do we need to be able to match attributes in a case insensitive way?
Merging is the only functionality offered by attribute sets that is not provided by macros. Is this a sufficient reason to keep attribute sets?
Which attribute values should be interpreted as attribute value templates?
Should there be a way of specifying that an attribute serves as a class attribute and then pattern syntax that treats class attributes specially?
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?
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()
.
Should the value of the constant
be specified in the content of the xsl:constant
element
rather than by a value
attribute?
Should there be some extensibility mechanism for the tree construction process? If so, how should it work? Should it be language independent?
Should XSL provide support for external data entities and notations?
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?
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.
Should XSL provide support for entity references?
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.
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?
Should the
select
attribute default in the same way as with
xsl:apply-templates
?
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?
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?
Should there be a way to get back from a element to the elements that reference it (eg by IDREF attributes)?
Should id()
be disallowed
after /
? This loses no functionality since
foo/id(@bar)
is equivalent to
id(foo/@bar)
.
Should id()
be renamed to
something less confusing like
element-with-id()
?
Should xsl:if
and
xsl:when
be unified into a single element?
Should we provide media-dependent imports as in CSS?
Provide a way for a stylesheet to import a stylesheet that is embedded in the document.
Should there be an instruction
that generates an error, like the error
procedure in
DSSSL?
Should there be a way to define local constants?
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?
Should macros be called something else?
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?
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?
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?
Should we provide the functionality
of CSS's @media
rule and if so how?
Should it be possible to create multiple result trees?
Should it be possible for patterns to select nodes in documents other than the source document?
How can the namespace and local part be accessed separately? This would be necessary to, for example, provide a "View Source" stylesheet.
Should patterns of
the form foo:*
or *:foo
be allowed? If so,
should *
match any element or any element without a
namespace URI?
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?
Should XSL support regular expressions for matching against any or all of pcdata content, attribute values, attribute names, element type names?
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?
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?
Should there be qualifiers that constrain an element to have an immediately preceding or following sibling of a particular type?
Should the
match
attribute have a default? Any node? Any child
node? The root node?
Should it be possible for a unique id to be specified in the content of an element instead of in an attribute?
Should the select
attribute have a default value of .
?
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?
Should there be support for following XPointers as well as IDs?