RE: Clarification on xsl:attribute requested

A personal response (I think this is something that the WG needs to consider
collectively).

Firsly, I assume I should read "Xalan" for "Xerces" throughout.

In the XSLT 1.0 errata we defined that <xsl:copy> and <xsl:copy-of> could be
used to copy namespace nodes from one tree to another. This gives an
indirect way of creating them dynamically, provided you have the
xx:node-set() extension. 

In XSLT 2.0 we've added xsl:namespace as a proper solution of the problem.

If you create an attribute node xx:att, then XSLT 1.0 specifies that a
namespace declaration xmlns:xx will be generated by the serializer, to make
the output namespace-well-formed. It doesn't say that a namespace node will
be produced in the result tree, but since there is no way of looking at the
result tree, you can't actually tell whether there is one there or not. This
means that when processors do allow you to look at the result tree (e.g.
using xx:node-set()) then the spec doesn't say whether there will be a
namespace node or not.

I'm not sure if the above is pertinent to your problem with Xalan: are you
looking at the serialized output, or at the result tree?

XSLT 2.0 introduces the notion of namespace fixup, which makes it clear that
a namespace node is indeed added to the result tree. I think that
introducing this concept to XSLT 1.0 is too big a change to do by means of
an erratum.

XSLT 1.0, and 2.0, are both quite explicit that when you create elements and
attributes on the result tree, there is no guarantee what prefix you will
get. We recently considered whether we should add a recommendation on the
prefix to be used in the case of xsl:namespace-alias, and the group was
firmly against it. So I think it's unlikely the group would want to accept
this proposed change.

I sympathize with your difficulties, and I hope you like the XSLT 2.0
improvements.

Regards,

Michael Kay

> 
> 
> 
> 
> A recent version of Xerces acts differently w.r.t. namespaces 
> compared to other implementations of XSLT.  While I believe 
> it is a bug, and we are reporting it, I think the XSLT 
> specification should be clarified to prevent future 
> occurrences of this problem.
> 
> The bug was reported by a user of Schematron who had 
> namespace problems.
> 
> XSLT prevents namespaces being added dynamically using 
> <xsl:attribute name="xmlns" namespace="blah" />
> 
> But Schematron (and programs like it) require a mechanism
> for dynamically setting namespaces, because these are sourced 
> from a schema not from a stylesheet. 
> 
> So the Schematron language provides an element
>  <sch:ns prefix="blah"  url="blahblah"  />
> which is converted to 
> <axsl:stylesheet>
>  <xsl:attribute name="concat(@prefix, ':dummy-namespace-attribute')"
>     namespace="@url" />
> ...
> 
> According to the XSLT spec the output <xsl:stylsheet
>  1)   should have an attribute  XXX:dummy-namespace-attribute="" 
>  2) should have a namespace declaration  xmlns:XXX="blahblah"
> 
> Xerces fails in this, and I think it needs to be clarified that 
> a namespace should be generated.
> 
> Now, as an extra wrinkle, the namespace spec does mention
> that we cannot guarantee that the same prefix will be used.
> 
> However, except for Xerces (which does not get up to
> that stage) all implementations of XSLT that I have tried
> do preserve that prefix, so we get the desired
>    <xsl:stylesheet  blah:dummy-namespace-attribute="" 
> xmlns:blah="blahblah"> which then allows the prefix to be 
> used in the XPaths and expressions that are generated.
> 
> So I would ask that this behaviour (which is standard) also 
> be clarified, to help any system that needs to dynamically 
> create namespaces.
> 
> To summarize what I would like in an XPath erratum:
> 
> 1) Clearer exposition that you may have to generate a 
> namespace declaration for an <xsl:attribute which supplies 
> its own namespace attribute.  And that if the Qname has a 
> prefix, the namespace declaration needs to be generated with 
> an appropriate prefix too.  (I believe this is what the 
> current spec implies, and it is how most implementations 
> work, and it is hard to see how else it could work.)
> 
> 2) Wording to the effect that if a namespace is used with 
> only a single prefix in a document, that prefix *should* be the one
> used in any output XML.    (Whether this can be overriden
> by user option, or what happen if the same prefix is bound to 
> different namespaces or if the same namespace is bound to 
> multiple prefixes are all issues that I do not think require 
> clarification, as they are outside my requirement.)
> 
> I believe this clarification merely reflects common practise
> and common sense.   It does not enshrine the prefix, but
> merely says "if the user has specified a prefix, you may
> as well use that rather than making up an arbitrary one."
> 
> Cheers
> Rick Jelliffe
> 
>

Received on Thursday, 27 June 2002 06:49:01 UTC