The phrase "if necessary to resolve conflicts" cited from the XSLT spec should be taken very broadly; binding the empty prefix to a non-null namespace in the case of an attribute is in conflict with the rule that for attribute nodes in the data model, the empty prefix is always bound to no-namespace.

I do think there's a rule missing from XDM here. The general policy in XDM is to define constraints that ensure every valid XDM document node can be serialized as a namespace-well-formed XML external entity.

Here's a possible resolution of this comment:
In XQuery Section 3.7.3.2, Computed Attribute Constructors, in the list of rules following "If the keyword 'attribute' is followed by a name expression", rewrite Rule 2 as follows:

2. If the atomized value of the name expression is of type xs:QName:

a. If the expanded QName returned by the atomized name expression has a namespace URI but has no prefix, it is given an implementation-dependent prefix. NOTE: This step is necessary because the default namespace does not apply to attributes. Therefore any attribute name that has a namespace URI must also have a prefix.

b. The resulting expanded QName (including its prefix) is used as the node-name property of the constructed attribute node.

This suggested resolution is subject to further discussion and approval by the Query Working Group.

--Don Chamberlin

Frans,
On April 18, 2007, the Query Working Group approved the resolution of this bug report described in Comment #2. This resolution will be implemented in a future erratum to the XQuery specification. If you agree with this resolution, please change the status of this bug report to "Closed."
Regards, 
Don Chamberlin (for the Query Working Group)

Yes, I agree with the resolution.

For testing purposes it would be convenient if the name of the prefix was deterministic, but I see no way to achieve that.


Frans

While testing, I came to think of queries like this:

<e>
{
    attribute {QName("http://www.w3.org/XML/1998/namespace", "space")} {"default"}
}
</e>

From what I can tell, implementations cannot randomly generate prefixes, it depends on the namespace URI. For the XML namespace as above, the "xml" prefix Must be use.

I doubt whether this justifies reconsideration, but I suggest the editorial change of adding an explanatory Note paragraph that sheds light on this.

Mike, I don't know whether this area applies to XSL-T as well, maybe it does.


Frans

The nearest equivalent in XSLT is

<xsl:attribute name="space" namespace="http://www.w3.org/XML/1998/namespace"/>

In that situation the system is required to invent a prefix, and the constraints on namespace fixup mean there is only one prefix it can validly invent...

I may be wrong here, but I believe that the changes suggested in Comment 2 is unnecessary.

The query:

<e>
        {
                attribute {QName("http://example.com/", "attr")} {()}
        }
</e>

will introduce a new namespace prefix, not when the attribute is created, but rather when it is copied, as a result of the rules given in XQuery 3.7.4 In-scope Namespaces of a Constructed Element.

i.e. I expect the result of

<element>
{
  let $name := QName("http://example.com/", "attr"),
      $attr := attribute {$name} {()} return
    ( $attr, text { prefix-from-QName(node-name($attr)) } )
}
</element>

to be of the form

<element xmlns:generated-prefix="http://example.com/" 
         generated-prefix:attr=""/ >

and not

<element xmlns:generated-prefix="http://example.com/" 
         generated-prefix:attr="">generated-prefix</element>

I've given more details in Bug 5723 and how it relates to Bug 4463 	 ([XQuery] Missing rules for misuse of the xmlns namespace).

I think the errata looks good as is. I think it is good to prevent isolated attribute nodes that has invalid names. For instance in the case they are part of the result set.

Frans - not sure what you mean here.  Bug 4463 prevents invalid attribute names.

I pieced together how the text would read with Bug 4463 and Comment #2 in place.

"If the keyword attribute is followed by a name expression, the name expression is processed as follows:

   1. Atomization is applied to the result of the name expression. If the result of atomization is not a single atomic value of type xs:QName, xs:string, or xs:untypedAtomic, a type error is raised [err:XPTY0004].

   2. If the atomized value of the name expression is of type xs:QName:

	a. If the expanded QName returned by the atomized name expression has a
	namespace URI but has no prefix, it is given an implementation-dependent
	prefix. NOTE: This step is necessary because the default namespace does not
	apply to attributes. Therefore any attribute name that has a namespace URI must
	also have a prefix.

	b. The resulting expanded QName (including its prefix) is used as the node-name
	property of the constructed attribute node.


   3. If the atomized value of the name expression is of type xs:string or xs:untypedAtomic, that value is converted to an expanded QName. If the string value contains a namespace prefix, that prefix is resolved to a namespace URI using the statically known namespaces. If the string value contains no namespace prefix, it is treated as a local name in no namespace. The resulting expanded QName (including its prefix) is used as the node-name property of the constructed attribute. If conversion of the atomized name expression to an expanded QName is not successful, a dynamic error is raised [err:XQDY0074].

A dynamic error [XQDY0044] is raised if the node-name of the constructed 
attribute node has any of the following properties:
(a) Its namespace prefix is xmlns
(b) It has no namespace prefix and its local name is xmlns
(c) Its namespace URI is http://www.w3.org/2000/xmlns/
(d) Its namespace prefix is xml and its namespace URI is not 
http://www.w3.org/XML/1998/namespace
(e) Its namespace prefix is other than xml and its namespace URI is 
http://www.w3.org/XML/1998/namespace"


Consider the query:

attribute { fn:QName('http://www.example.com/', 'xmlns') } { 'foo' }

Because this attribute will have magically gained a prefix by rule (2a), this won't hit rule "(b) It has no namespace prefix and its local name is xmlns".

That doesn't seem intuitive to me at least.  Nor does it seem intuitive that

empty(
  prefix-from-QName(
    node-name(
      attribute { fn:QName('http://www.example.com/', 'foo') } { 'foo' }
    )
  )
)

should not be false.

XQuery 3.7.4 rules will introduce a namespace prefix when copying such an attribute.

For a further example, consider


let $x := attribute { fn:QName('http://www.example.com', 'foo') } { () } return
  <root>
    <element xmlns:ns1="http://www.example.com">
      { $x }
    </element>,
    <element xmlns:ns2="http://www.example.com">
      { $x }
    </element>,
  </root>

It seems to me preferable for the result to be:

<root>
  <element xmlns:ns1="http://www.example.com" ns1:foo=""/>,
  <element xmlns:ns2="http://www.example.com" ns2:foo=""/>,
</root>

rather than:

<root>
   <element xmlns:ns1="http://www.example.com" ns1:foo=""/>,
   <element xmlns:ns2="http://www.example.com" xmlns:ns1="http://www.example.co
m" ns1:foo=""/>,
</root>

XDM erratum E004

http://www.w3.org/XML/2007/qt-errata/xpath-datamodel-errata.html#E004

makes it clear that an attribute node whose name is in a namespace must have a prefix. This is true whether or not the attribute node is attached to an element. Therefore a query processor must invent a prefix at the time the attribute node is created, it cannot leave it until the attribute acquires a parent (unless, of course, the user can't tell the difference).

Of course, it could have been done differently and perhaps even better, but that's not the point.

Mike - thanks for pointing that out.  Shame though...

Did Bug 4487 arise from this bug, or was it identified separately?
	

> Did Bug 4487 arise from this bug, or was it identified separately?

I think we were having a general purge of such issues at the time.

Michael Kay