4443 2007-04-02 08:10:42 +0000 [XQuery] Unspecified how unprefixed attributes with namespace URIs are to be treated 2008-06-26 14:19:46 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 Recommendation Other Linux CLOSED FIXED P2 normal --- 1 frans.englich chamberl mike tim public-qt-comments oldest_to_newest 14624 0 frans.englich 2007-04-02 08:10:42 +0000 The following query: <e>         {                 attribute {QName("http://example.com/", "attr")} {()}         } </e> produce an attribute whose name doesn't have a prefix but does have a non-empty namespace URI, and is added to an element. This cannot be serialized without a prefix for the attribute, which above is absent. Apparently this is not discussed in the specifications. It might be useful to see XSL-T's take on this. Sections 5.7.3 Namespace Fixup and 11.3 Creating Attribute Nodes Using xsl:attribute may be of particular importance. (XSL-T 5.7.3 says "Namespace fixup may, if necessary to resolve conflicts, change the namespace prefix contained in the QName value that holds the name of an element or attribute node," but I don't see how such conflicts can occur in XQuery due to XQDY0025. But maybe there's some other additional namespace case that XQuery doesn't cover.) First raised on w3c-xml-query-wg@w3.org(member-only link): http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2007Apr/0000.html 14627 1 mike 2007-04-02 09:32:39 +0000 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. 14649 2 chamberl 2007-04-03 17:35:02 +0000 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 14746 3 chamberl 2007-04-18 20:37:02 +0000 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) 14848 4 frans.englich 2007-04-23 08:51:04 +0000 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 14851 5 frans.englich 2007-04-23 12:38:18 +0000 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 14852 6 mike 2007-04-23 13:29:25 +0000 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... 20803 7 tim 2008-06-24 15:03:19 +0000 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). 20841 8 frans.englich 2008-06-25 11:28:46 +0000 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. 20853 9 tim 2008-06-25 12:57:28 +0000 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. 20894 10 tim 2008-06-26 10:55:23 +0000 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> 20923 11 mike 2008-06-26 13:18:38 +0000 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. 20925 12 tim 2008-06-26 13:24:23 +0000 Mike - thanks for pointing that out. Shame though... Did Bug 4487 arise from this bug, or was it identified separately? 20931 13 mike 2008-06-26 14:19:46 +0000 > 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