This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the XQTS query: (:*******************************************************:) (: Test: K2-CopyNamespacesProlog-1 :) (: Written by: Frans Englich :) (: Date: 2007-07-17T17:04:39+01:00 :) (: Purpose: Use no-preserve, inherit with the default namespace. :) (:*******************************************************:) declare copy-namespaces no-preserve, inherit; <doc> <a>{<b xmlns:p="q"/>}</a> <a><b xmlns:p="q"/></a> </doc> then expected result is: <doc> <a><b></b></a> <a><b xmlns:p=\"q\"></b></a> </doc> which we don't quite understand. On the one hand, reading: http://www.w3.org/TR/xquery/#id-content seems to suggest that copying (and therefore the influence of the copy namespaces mode) only comes into play when dealing with enclosed expressions. However, reading the Formal Semantics document http://www.w3.org/TR/xquery-semantics/#id_element_constructor I can't see anything which wuold result in the normalized forms of these two expressions being different. Specifically, there doesn't seem to be any special rule for enclosed expressions. Or have I missed something? We raised this in Bug 4864. Mike Kay has kindly confirmed that he believes the result to be correct; "It's fairly bizarre and probably unintended that these two expressions produce different results, but I think the XQuery language book makes it clear that they do." but didn't dare venture an opinion on how this behaviour is reflected in the Formal Semantics.
With respect to the content of the two 'a' direct element constructors in the test case, I'll confirm that the FS does indeed normalize them to the same thing, which does not correctly reflect the semantics given in the XQuery spec.
Interestingly, the XQueryX version of this query represents the content of the two <a> tags identically. This suggests that the distinction between enclosed expressions and 'normal' element content has been missed there too.
(In reply to comment #2) > Interestingly, the XQueryX version of this query represents the content of the > two <a> tags identically. This suggests that the distinction between enclosed > expressions and 'normal' element content has been missed there too. > If so that's a bug in the translation, earlier test cases all had this fixed in line with the resolution of bug #2257 David
The XQueryX from XQTS (1.0.3 dev) is below. I can't quite see how XQueryX should be used to distinguish the two forms, unless the enclosed element b is represented as a computed element constructor. Could you please comment? <?xml version="1.0"?> <xqx:module xmlns:xqx="http://www.w3.org/2005/XQueryX" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2005/XQueryX http://www.w3.org/2005/XQueryX/xqueryx.xsd"> <xqx:mainModule> <xqx:prolog> <xqx:copyNamespacesDecl> <xqx:preserveMode>no-preserve</xqx:preserveMode> <xqx:inheritMode>inherit</xqx:inheritMode> </xqx:copyNamespacesDecl> </xqx:prolog> <xqx:queryBody> <xqx:elementConstructor> <xqx:tagName>doc</xqx:tagName> <xqx:elementContent> <xqx:elementConstructor> <xqx:tagName>a</xqx:tagName> <xqx:elementContent> <xqx:elementConstructor> <xqx:tagName>b</xqx:tagName> <xqx:attributeList> <xqx:namespaceDeclaration> <xqx:prefix>p</xqx:prefix> <xqx:uri>q</xqx:uri> </xqx:namespaceDeclaration> </xqx:attributeList> </xqx:elementConstructor> </xqx:elementContent> </xqx:elementConstructor> <xqx:elementConstructor> <xqx:tagName>a</xqx:tagName> <xqx:elementContent> <xqx:elementConstructor> <xqx:tagName>b</xqx:tagName> <xqx:attributeList> <xqx:namespaceDeclaration> <xqx:prefix>p</xqx:prefix> <xqx:uri>q</xqx:uri> </xqx:namespaceDeclaration> </xqx:attributeList> </xqx:elementConstructor> </xqx:elementContent> </xqx:elementConstructor> </xqx:elementContent> </xqx:elementConstructor> </xqx:queryBody> </xqx:mainModule> </xqx:module>
(In reply to comment #4) > The XQueryX from XQTS (1.0.3 dev) is below. I can't quite see how XQueryX > should be used to distinguish the two forms, unless the enclosed element b is > represented as a computed element constructor. Could you please comment? > I don't think there is a "natural" way in xqueryx to encode this. (Just checked the xqueryx.xsl stylesheet for every way that it can be coerced into adding { } around things in the generated xquery text. You could do (the xqueryx equivalent of) <a>{(<b xmlns:p="q"/>)}</a> (that ism throw in an xqx:parenthesizedExpr to "hide" the element constructor but whether or not you consider that a faithful translation of the original <a>{<b xmlns:p="q"/>}</a> I'm not qualified to answer. In that early development of XqueryX I sent many bug reports asking essentially that some notion of equivalence be defined such that one could ask the question (and test) whether an XqueryX expression was equivalent to a given XQuery one, but the decision of the WG was consistently that such a round trip test was not a requirement of XQueryX development.
Your suggestion of using xqx:parenthesizedExpr to differentiate these two forms would work well if xqx:parenthesizedExpr hadn't been removed from the schema! From: http://www.w3.org/TR/xqueryx/#Schema "removed the unnecessary <xqx:parenthesizedExpr/> element (#3333)" However, that element is used in Example 4 at: http://www.w3.org/TR/xqueryx/#Example4-XQueryX
oops, sorry I must have picked up an old copy of the schema. Of course I should have known about it in anycase as the removal seems to have been triggered by http://www.w3.org/Bugs/Public/show_bug.cgi?id=3333#c3 which was a comment from me.... xqx:sequenceExpr is available and would do the same job in this context, I think. David
Thanks.
I wonder if we at all want this distinction. I agree that the XQuery book makes the distinction, but that FS is out of alignment, the trouble of achieving the same thinhg in XQueryX(if at all possible?), and surprised implementors, suggests to me that maybe it should be avoided. What does the distinction add to the language? Can it be safely removed?
(In reply to comment #9) > the trouble of achieving the same thinhg in XQueryX(if at all possible?) Fixing the XQueryX isn't hard (see comment #7) > > What does the distinction add to the language? Can it be safely removed? > Any language can be changed of course but this would be quite a big change. The declare copy-namespaces declaration only affects nodes that are being copied not nodes that are being created. It's a general feature of xquery I think that there is little syntactic difference between querying copying and creating nodes, (this is in contrast to xslt where these are far more distinct, and all of them are far more verbose) in xquery you can go /a/<x><y/></x>/<x>{<z/>}</x> to query existing nodes (a) generate new nodes (x,y) or copy (newly created) nodes (z), XSLT forces you to breakout of the path expression and use xsl:element or literal result elements (to create) or xsl:copy-of (to copy) but surely it's an explicit design goal of the XQuery syntax to be more compositional and allow these things to be mixed. So the small syntactic difference here is a natural (if initially surprising) feature of XQuery rather than something that needs changing David
>I wonder if we at all want this distinction. (that is, the distinction between <a><b/></a> and <a>{<b/>}</a>) Personally, I don't think the distinction is useful, and I would be quite happy if the first form were defined as being a shorthand for the second. I'm not sure there's a good case for changing this by erratum, but I think it's a candidate for an XQuery 1.1 change.
This was discussed on Shrove Tuesday, 5 February 2008. I was actioned to propose wording that reflected a sentiment to make <a><b/></a> behave in the same way as <a>{<b/>}</a>. It is believed that if we make this change in the XQuery language book, no changes will be needed to XQueryX or to the formal semantics. I believe the change can be implemented fairly easily. Specifically, in section 3.7.1.3, change clause 1.d to read in its entirety: d. Each nested direct constructor is evaluated as if it appeared in an enclosed expression. For example, <a><b/><b/></a> is evaluated as if it were written <a>{<b/>}{<b/>}</a>. (I withdraw my earlier opinion that this change is inappropriate for an erratum. The various specifications are in conflict and this is the simplest way to bring them into alignment.)
I may be missing something, but I believe a change to the Formal Semantics will still be required. The FS document does not seem to cover the copying of nodes and how the copy-namespaces declaration affects it. See 4.7.3.1 Computed Element Constructors, Dynamic Evaluation. In FS 5.9 Copy-Namespaces Declaration, it states that the copy-namespace declaration does not have any effect on the static context, nor on the dynamic context. Isn't this a little odd, given its influence during evaluation?
But 4.7.3.1 in the FS states: This document does not formally specify how namespaces are copied. The semantics of namespaces copying in element constructors can be found in [XQuery 1.0: An XML Query Language]. Surely that's adequate?
Perhaps, but I'm not sure. Do the dynamic evaluation rules for element constructors even hint that there is any copying going on?
(In reply to comment #12) > d. Each nested direct constructor is evaluated as if.... If this change is made don't you want to apply it also to top level element constructors not just nested ones? As I understand the proposal it would make declare copy-namespaces no-preserve, inherit; <a xmlns:p="q"><b/></a> produce <a xmlns:p="q"> <b/> </a> (as now) but declare copy-namespaces no-preserve, inherit; <a><b xmlns:p="q"/></a> which currently produces <a> <b xmlns:p="q"/> </a> to change to produce <a> <b/> </a> If it is thought desirable to change the second example to lose the generated namespace declaration, why not the first? David
Regarding Comment #16, wouldn't serialization of the result have an effect too, since the sequence normalization process for a sequence is equivalent to constructing a document node using the XQuery expression: document { for $s in $seq return if ($s instance of document-node()) then $s/child::node() else $s } i.e. wouldn't <a xmlns:p="q"><b/></a> produce <a xmlns:p="q"> <b/> </a> but serialize to <a> <b/> </a> Note that the specification doesn't make it clear what the copy-namespaces mode might be for the above.
(In reply to comment #17) > Regarding Comment #16, wouldn't serialization of the result have an effect too, I don't think so (and the results I posted were generated by saxon9's serialiser) the $s/child::node() construct in the serialisation spec doesn't make clear what copy-namespace settings should be in effect, but if (as stated0 the intention is that it be teh same as the xsl:copy instruction quoted a few lines earlier then namespaces should be copied, so you do not lose the namespace declarationj during serialisation.
(In reply to comment #15) > Do the dynamic evaluation rules for element constructors > even hint that there is any copying going on? Nope. I believe the intent is that the copying happens within the pseudo-function fs:item-sequence-to-node-sequence. You can't currently deduce that from the prose semantics in FS 7.1.5, but that should change once Bug 3655 is fixed.
In discussion on 12 Feb 2008 there was some sentiment to adopting David Carlisle's suggestion in comment #16 that the no-preserve effect should apply to namespace declarations in all element constructors, and not only to those in "directly enclosed" element constructors. This involves changing the first two bullets of 3.7.1.2 to read: <quote> # If the prefix of the attribute name is xmlns, then the local part of the attribute name is interpreted as a namespace prefix and the value of the attribute is interpreted as a namespace URI. This prefix and URI are added to the statically known namespaces of the constructor expression (overriding any existing binding of the given prefix). If the namespace URI is a zero-length string and the implementation supports [XML Names 1.1], any existing namespace binding for the given prefix is removed from statically known namespaces of the constructor expression. If the namespace URI is a zero-length string and the implementation does not support [XML Names 1.1], a static error is raised [err:XQST0085]. It is implementation-defined whether an implementation supports [XML Names] or [XML Names 1.1]. # If the name of the namespace declaration attribute is xmlns with no prefix, the value of the attribute is interpreted as a namespace URI. This URI specifies the default element/type namespace of the constructor expression (overriding any existing default). If the namespace URI is a zero-length string, the default element/type namespace of the constructor expression is set to "none". <aside>There really isn't any good reason why this should have a dependency on XML Namespaces 1.1</aside> <provisional> Furthermore, if copy-namespaces mode specifies "preserve", and if the namespace URI is not a zero-length string, then the namespace binding implied by the above rules is added to the in-scope namespaces of the constructed element. </provisional> </quote> Now, this doesn't say anything about namespace undeclarations like xmlns="" or xmlns:p="". The current spec talks about these *removing* a namespace binding from the constructed element - which is rather odd because how can they have a binding that needs removing? The answer seems to lie in section 3.7.4, which appears to overlap 3.7.1.2 in various ways (and is not referenced from it, which caused me a lot of grief in writing this proposal!) So I think the answer is to remove the text above marked <provisional>, and instead add after the three bullets: <para>Namespace declarations also cause in-scope namespace bindings to be added to the constructed element node, as described in section 3.7.4.</para> In 3.7.4, replace the first two bullets by: * if copy-namespaces mode includes "preserve", a namespace binding is created for each namespace declared by a namespace declaration attribute in the current element constructor or in an enclosing direct element constructor. (A namespace is so declared if the namespace URI is not a zero-length string, and if the declaration is not overridden within the current element constructor or an intermediate constructor). Delete the Note, which is no longer true. Finally, apply the change described in comment #12
(In reply to comment #20) > > The answer seems to lie in section 3.7.4, which appears to overlap 3.7.1.2 > in various ways (and is not referenced from it, which caused me a lot of > grief in writing this proposal!) So I think the answer is to remove the > text above marked <provisional>, and instead add after the three bullets: > > <para>Namespace declarations also cause in-scope namespace bindings to be > added to the constructed element node, as described in section 3.7.4.</para> If 3.7.1.2 is no longer responsible for modifying in-scope namespaces, then in 3.7.1.3 point 5.f, you'd probably want to change <current> in-scope-namespaces consist of all the namespace bindings resulting from namespace declaration attributes as described in 3.7.1.2 Namespace Declaration Attributes, and possibly additional namespace bindings as described in 3.7.4 In-scope Namespaces of a Constructed Element. </current> to <new> in-scope-namespaces are computed as described in 3.7.4 In-scope Namespaces of a Constructed Element. </new> (The same as 3.7.3.1, point 4.f.)
I was not present at the discussion on 12 Feb 2008, but I must say that I find it very strange for the behavior of a direct element constructor to be influenced by copy-namespaces mode. Consider the following example: <a xmlns:p="uri1">{xs:QName("p:foo")}</a> The user has constructed an element with a namespace binding for the prefix "p". He expects this namespace binding to exist in the constructed element node. He has not copied anything and has no reason to expect copy-namespaces mode to have any influence at all. He expects the following serialized output: <a xmlns:p="uri1">p:foo</a> Instead, the proposal in Comment #20 throws away the namespace binding that the user has specified and generates this serialized output: <a>p:foo</a> I cannot explain to this user why we threw away his namespace binding. I do not think that users are well served by this proposal. I prefer to keep the semantics exactly as currently specified in the language document. Nested direct element constructors do not copy anything, and they are not influenced by copy-namespaces mode. Enclosed expressions, on the other hand, generate references to nodes; these nodes are typically pre-existing and making copies of them is reasonably governed by copy-namespaces mode. The examples in this bug report, in which the entire content of a direct constructor is an enclosed expression containing another direct constructor, are a strange usage. There is no reason to do this. It will never occur in nature. We should not warp our rules on account of this anomalous usage. In particular, we should not throw away namespace bindings that the user has taken the trouble to write.
For the record, I agree fully with comment #22, (as may be seen by my initial comment #10) My comment #16 suggested making further changes (to keep the language consistent) if any change is to be made, but I think no change at all is preferable.
In http://www.w3.org/Bugs/Public/show_bug.cgi?id=4869#c6, Tim Mills observed that "However, that element is used in Example 4 at: http://www.w3.org/TR/xqueryx/#Example4-XQueryX" That bug has been reported in http://www.w3.org/Bugs/Public/show_bug.cgi?id=4963 and fixed in the XQueryX Errata document published at http://www.w3.org/XML/Group/xsl-query-specs/errata/xqueryx-errata.html#E2 Hope this helps, Jim
The Formal semantics does not model the behavior related to copying of namespace nodes. This is one of those aspects of the semantics which we explicitely left of since it did not affect the static semantics. There is an explicit statement to that effect at the beginning of Section 4.7.3.1: "This document does not formally specify how namespaces are copied. The semantics of namespaces copying in element constructors can be found in [XQuery 1.0: An XML Query Language]."
How interesting. I used the XQuery 1.0 grammar applet to convert the query provided in the original entry: declare copy-namespaces no-preserve, inherit; <doc> <a>{<b xmlns:p="q"/>}</a> <a><b xmlns:p="q"/></a> </doc> into XQueryX: <?xml version="1.0"?> <xqx:module xmlns:xqx="http://www.w3.org/2005/XQueryX" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2005/XQueryX http://www.w3.org/2005/XQueryX/xqueryx.xsd"> <xqx:mainModule> <xqx:prolog> <xqx:copyNamespacesDecl> <xqx:preserveMode>no-preserve</xqx:preserveMode> <xqx:inheritMode>inherit</xqx:inheritMode> </xqx:copyNamespacesDecl> </xqx:prolog> <xqx:queryBody> <xqx:elementConstructor> <xqx:tagName>doc</xqx:tagName> <xqx:elementContent> <xqx:elementConstructor> <xqx:tagName>a</xqx:tagName> <xqx:elementContent> <xqx:elementConstructor> <xqx:tagName>b</xqx:tagName> <xqx:attributeList> <xqx:namespaceDeclaration> <xqx:prefix>p</xqx:prefix> <xqx:uri>q</xqx:uri> </xqx:namespaceDeclaration> </xqx:attributeList> </xqx:elementConstructor> </xqx:elementContent> </xqx:elementConstructor> <xqx:elementConstructor> <xqx:tagName>a</xqx:tagName> <xqx:elementContent> <xqx:elementConstructor> <xqx:tagName>b</xqx:tagName> <xqx:attributeList> <xqx:namespaceDeclaration> <xqx:prefix>p</xqx:prefix> <xqx:uri>q</xqx:uri> </xqx:namespaceDeclaration> </xqx:attributeList> </xqx:elementConstructor> </xqx:elementContent> </xqx:elementConstructor> </xqx:elementContent> </xqx:elementConstructor> </xqx:queryBody> </xqx:mainModule> </xqx:module> The constructors for the two a elements are exactly the same. Looking at the XQueryX schema, I see: <xsd:element name="elementContent" type="exprList"/> <xsd:complexType name="elementConstructor"> <xsd:complexContent> <xsd:extension base="expr"> <xsd:sequence> <xsd:element name="tagName" type="QName"/> <xsd:element ref="attributeList" minOccurs="0"/> <xsd:element ref="elementContent" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> I don't see any way to write these two constructors any differently to distinguish them. Looking further, I see the following rules in the XQueryX stylesheet: <xsl:template match="xqx:elementContent"> <xsl:for-each select="*"> <xsl:if test="not(self::xqx:elementConstructor)"> <xsl:value-of select="$LBRACE"/> </xsl:if> <xsl:apply-templates select="."/> <xsl:if test="not(self::xqx:elementConstructor)"> <xsl:value-of select="$RBRACE"/> </xsl:if> </xsl:for-each> </xsl:template> <xsl:template match="xqx:elementConstructor"> <xsl:value-of select="$LESSTHAN"/> <xsl:apply-templates select="xqx:tagName"/> <xsl:apply-templates select="xqx:attributeList"/> <xsl:value-of select="$GREATERTHAN"/> <xsl:apply-templates select="xqx:elementContent"/> <xsl:value-of select="$LESSTHAN"/> <xsl:value-of select="$SLASH"/> <xsl:apply-templates select="xqx:tagName"/> <xsl:value-of select="$GREATERTHAN"/> </xsl:template> If direct element constructors are nested, then braces will not be generated. Otherwise, braces are generated. The upshot of all of this? I believe that if we retain the semantics that cause these two constructors to create different elements, then XQueryX needs to be changed.
If direct element constructors are nested, then braces will not be generated. Otherwise, braces are generated. Yes that behaviour of the xqueryx stylesheet was added specifically because of this issue to avoid adding braces around nested constructors as the copy namespaces behaviour is different. see comment #3 what you observe is simply a bug in the translator that was used. I don't see any way to write these two constructors any differently to distinguish them. see comment #5 as corrected in comment #7 David
Thanks, David. I agree with you. Next time I will definitely read the comments between the first comment and the recent comments at the end.
If we adopt my proposal in Bug 3771 comment #8, then the original query's constructors: <a>{<b xmlns:p="q"/>}</a> <a><b xmlns:p="q"/></a> would normalize to: element a { fs:B( fs:A(( element b {()} { namespace p {"q"} } )) ) } element a { fs:B( element b {()} { namespace p {"q"} } ) } So only in the first case would the 'b' element be subject to fs:A's node-copying semantics.
The WG has approved the proposal in Bug 3771 comment #8, so I am marking this bug as resolved-fixed. If you agree, please close it.
Michael, with the changes from Bug 3771 in place, how should I read references to fs:item-sequence-to-node-sequence in the XQuery Update CR?
(In reply to comment #31) > Michael, with the changes from Bug 3771 in place, how should I read references > to fs:item-sequence-to-node-sequence in the XQuery Update CR? See Bug 5666 for a partial response.
... and see Bug 3771 Comment #15 for the rest of the response.
The portion of Bug 3771 relevant to this Bug has been entered as FS erratum E029, and the fix for it has been committed to the source files for the next edition of the FS document. Consequently, I'm marking this Bug CLOSED.