Lists Home |
Date Index |
David Carlisle wrote:
> > Where such values are specified to be constants, is there a reason not
> > to parse them immediately rather than to wait until the template element
> > is processed.
> You seem to be assuming that XST processing is interleaved with the XML
> parsing of the stylesheet. This isn't always the case, MSXML for example
> aways just uses a complete DOM as the input stylesheet: that DOM could
> come from anywhere. If the stylesheet was parsed at all (rather than
> having been built using dom methods) the whole stylesheet is parsed
> before the XSLT engine ever sees it.
Where the constant expressions are interpreted by the XSLT processor
before it processes the tree, the result is the same as when the
interpretation is interleaved with parsing the tree. The issue is
whether, as is the case where the values are templates rather than
constants, the processor requires the bindings in order to interpret the tree.
> > the only (obvious) way to predict the
> > result for all documents is to restrict the value domain to eliminate
> > prefixes. For example, by restricting the domain from QNames to NCNames
> in something like the name attribute of xsl:element then elimnating
> prefixes doesn't seem to change anything, even if it's an NCName it is
> subject to the default namespace so is just as "variable" as a name with
> a prefix, it just happens to have a prefix that is the empty string (in
> which case, as a matter of surface syntax, you also miss off the ":")
The domain restriction is accompanied by the requirement that the
namespace attribute be present. That is, the namespace name is computed
explicitly rather than imputed from a prefix.
> It's different for QNames in XPath (1.0) expressions as there NCNames have
> fixed interpretation as being in the null namespace.
> But your comment seems to imply that in the current specification you
> think there is something unpredicatble (rather than something that you
> think is a poor design).
When the latter leads to the former...