RE: Parentless attribute nodes and namespaces, text says it is disallowed, processors appear to allow it

I understand, but here I deliberately use a namespace *not* present on the element. This namespace is carried along, as is the prefix (if I use a QName with a prefix, the code works, which is interesting, because the prefix is not yet in scope).

I don't mind this behavior, I find it convenient, but it is not in line with the text: 

We say "because they have no namespace nodes associated with them" 

This is true, of course, but then we say:  "A parentless attribute node is not
permitted to contain namespace-sensitive content"

I assume this is also true, but the status-quo is that a parentless attribute node *does* contain namespace sensitive content. And except for the namespace node as a node, you can access it (local name, name, qname, namespace-uri).

Then we say " because there is no information enabling the prefix
 to be resolved to a namespace URI"

Technically probably also true, but again, the status-quo is that processors carry this information along anyway, and the prefix is resolved to the namespace URI given in the xsl:attribute instruction.

In fact, I tried the same code with the same QNames and the namespace fixup kicks in, as it should:

<xsl:variable name="attr" as="attribute()+">
    <xsl:attribute name="t:test" namespace="urn:my" />
    <xsl:attribute name="t:test2" namespace="urn:my2" />
</xsl:variable>

Leads to (Saxon) <x xmlns:t="urn:my2" xmlns:t_3="urn:my" t:test2="" t_3:test="" />
And (Exselt) <x xmlns:t="urn:my2" xmlns:t_1="urn:my" t:test2="" t_1:test="" />

Which I think is desirable behavior. The alternative is to raise an error upon creating a parentless attribute node with a namespace or QName.

> Try with a value that refers to a prefix bound in the context of its
> creation (as it is necessary for instance when generating an XML

I think you mean something like:

<xsl:variable name="attr" as="attribute()+" xmlns:t="urn:other">
    <xsl:attribute name="t:test" />
</xsl:variable>

Which works as expected as well, the namespace is correctly (?) inherited and the parentless attribute can be carried around and copied to an element as its parent and the element will then get the necessary namespace declarations. If the prefix is already bound on the new parent element, the prefix gets fixed up.

Cheers,
Abel


> -----Original Message-----
> From: fgeorges@gmail.com [mailto:fgeorges@gmail.com] On Behalf Of
> Florent Georges
> Sent: Wednesday, September 23, 2015 9:53 PM
> To: Abel Braaksma
> Cc: Public XSLWG
> Subject: Re: Parentless attribute nodes and namespaces, text says it is
> disallowed, processors appear to allow it
> 
> Hi,
> 
> I have not checked the specific verses, but the namespace declaration
> is created because the name of the attribute uses it.  That has
> nothing to do with a namespace node that would be carried by the
> attribute node.
> 
> Try with a value that refers to a prefix bound in the context of its
> creation (as it is necessary for instance when generating an XML
> Schema, with type="my:type").  The user has to be double careful with
> the binding for prefix "my".
> 
> With elements, they carry all the machinery to ensure the namespace
> bindings.  Attribute nodes do not.
> 
> Regards,
> 
> --
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/
> 
> 
> On 23 September 2015 at 21:30, Abel Braaksma wrote:
> > I was wondering if the statement we have about parentless attribute
> nodes is still valid. Under 5.8 Sequence Constructors we say:
> >
> > <quote>
> > Parentless attribute nodes require particular care because they have no
> namespace nodes associated with them. A parentless attribute node is not
> permitted to contain namespace-sensitive content (for example, a QName
> or an XPath expression) because there is no information enabling the prefix
> to be resolved to a namespace URI. Parentless attributes can be useful in an
> application (for example, they provide an alternative to the use of attribute
> sets: see 10.2 Named Attribute Sets) but they need to be handled with care.
> > </quote>
> >
> > For instance, if I write something like this:
> >
> > <xsl:template match="x">
> >    <xsl:copy>
> >      <xsl:variable name="attr" as="attribute()">
> >         <xsl:attribute name="test" namespace="urn:myns" />
> >      </xsl:variable>
> >      <xsl:copy-of select="$attr" />
> >    </xsl:copy>
> > </xsl:template>
> >
> > It creates <x ns1:test="" xmlns:ns1="urn:myns" />
> >
> > I doubt it should fail as the test suggests. When I try this with several
> processors, they all create a new namespace node with the URI of the
> namespace attribute and place the new attribute in that namespace. This
> seems reasonable, but if we allow that as a proper status-quo-in-the-wild
> (tested in XSLT 2.0 and 3.0), then perhaps we should reconsider that Note. Or
> am I misinterpreting it?
> >
> > Also, what is meant by "or an XPath expression"? A namespace node does
> not *contain* an XPath expression.
> >
> > The above variable $attr does return a namespace with fn:namespace-
> uri(), a QName with fn:name() and a local name with fn:local-name(). I
> cannot use fn:in-scope-prefixes() (requires an element) but I can see the
> prefix with fn:name().
> >
> > This looks to me like a contradictio-in-terminus...
> >
> > Cheers,
> > Abel
> >
> >

Received on Thursday, 24 September 2015 07:26:42 UTC