[
Lists Home |
Date Index |
Thread Index
]
Richard Tobin wrote:
>
> >> >> Only the XSLT processor knows what the attribute means.
> >>
> >> >Since it knows that as soon as the element tag has been parsed, it could
> >> >well act on that knowledge and discard it.
> >>
> >> I can't follow that - too many "it"s. What knows what as soon as the
> >> element tag has been parsed?
> >
> >In the cited passage, "the XSLT processor".
>
> How can the XSLT processor know it as soon as the element tag has been
> parsed? The XSLT processor doesn't parse element tags, the parser does!
> After parsing, the element names have been resolved but the QName in the
> attribute value hasn't (because the parser doesn't know it's a QName).
> So the parser has to pass the namespace map to the XSLT processor.
Which is the point at which the "element tag has been parsed."
>
> >The last assertion confuses me. Where all qualified names have been
> >interpreted, that is, where "[the downstream processor has] interpreted
> >the element", what does a relation between prefixes and namespace names mean?
>
> Sorry, by "the downstream processor has interpreted the element" I
> meant "... interpreted everything in the element's attribute values
> and text content". So long as there is text in the attributes or
> content that might be interpreted as a QName, the map has to be kept.
At issue is the point at which this interpretation happens. I read the
XSLT spec to say that it may happen as soon as the StartElement callback
(or its equivalent) is made. There are cases where the spec does permits
attribute value templates to range over domains which challenge this
conclusion. In particular those which yield results in the QName domain.
Yet, when one considers a form such as
<xsl:element
name = { qname }
namespace = { uri-reference }
use-attribute-sets = qnames >
...
the only interpretation which leads to predicatable transformations is
that the domain of the name attribute must be restricted to ncname.
Given, for instance the discussions of the use of something like the
name function, as in "XSLT Programmer's Reference", permitting the name
attribute to range over qnames does not work.
By this I do not mean that one cannot figure out how to make it mostly
work, I mean that one cannot guarantee that it will always work.
Where value templates which are intended to yield names produce the
local part only, the XSLT processor need not concern itself with the
effective prefix-namespace bindings at the time it is evaluating the
value template. neither those in the source tree, nor those present in
the result tree, nor those in the stylesheet tree. any qnames are
limited to constant values which can already have been computed at the
point where the respective StartElement callback occurred.
Are there transformations which can be expressed where the name
attribute ranges over qnames, which cannot be expressed where it is
restricted to ncnames and the namespace name is computed as the value of
the anscilliary namespace attribute rather than imputed through the
result qname?
Would this restriction break applications that work today? By which I
mean that they produce the intended transform for all documents rather
than for only a subset which is encoded with specific prefixes.
...
|
