This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Constr-ws-tag-6.xq is declare boundary-space preserve; <elem> </elem> so clearly here the white space needs to be preserved. Constr-ws-tag-6.xqx (in current.zip in cvs) encodes this as <xqx:elementConstructor> <xqx:tagName>elem</xqx:tagName> <xqx:elementContent/> </xqx:elementConstructor> with empty content. The same is probably true of other tests with boundary space set to preserve. for comparison xq2xqx (now, not in the public copy) encodes this as <xqx:elementConstructor> <xqx:tagName>elem</xqx:tagName> <xqx:elementContent> <xqx:stringConstantExpr> <xqx:value> </xqx:value> </xqx:stringConstantExpr> </xqx:elementContent> </xqx:elementConstructor> David
Adding my support to David's proposed solution, I want to be sure that nobody misunderstands and thinks that a "shorter" solution such as: <xqx:elementConstructor> <xqx:tagName>elem</xqx:tagName> <xqx:elementContent> </xqx:elementContent> </xqx:elementConstructor> is appropriate. This solution does not produce the required text node containing three space characters. (Just being thorough...)
xq2xml reports the following xqueryx files as not having a white space text node where one is expected (although in some cases this is due to mishandling of character references, bug #2441) David Constr-attr-ws-3 Constr-attr-ws-4 Constr-attr-ws-5 Constr-cont-eol-3 Constr-cont-eol-4 Constr-ws-tag-6 Constr-ws-tag-7 Constr-ws-tag-8 Constr-ws-tag-9 Constr-ws-enclexpr-13 Constr-ws-enclexpr-14 Constr-ws-enclexpr-15 Constr-ws-enclexpr-19 Constr-ws-enclexpr-20 Constr-ws-enclexpr-21 Constr-ws-enclexpr-22 Constr-ws-enclexpr-23 Constr-ws-enclexpr-24 Constr-ws-genchref-1 Constr-ws-genchref-2 Constr-ws-genchref-3 Constr-ws-genchref-4 Constr-ws-adjcdata-1 Constr-ws-adjcdata-2 Constr-ws-adjcdata-3 Constr-ws-xmlspace-2 boundary-space-002 boundary-space-005 boundary-space-006 boundary-space-016 K-CodepointToStringFunc-9 K-CodepointToStringFunc-10 K-CodepointToStringFunc-13 K-CodepointToStringFunc-16 fn-translate3args-2
I am back to working on XQueryX, so I am looking at this issue, among others... I originally thought of doing what you describe, David. Unfortunately, there doesn't seem to be a way to encode whitespace or boundary-space declarations in XQueryX, which means that the meaning of XQuery is lost after one converstion to XQueryX and back to XQuery with the stylesheet (since the declarations are gone in the final XQuery, the spaces will be stripped on subsequent XQueryX conversions). I guess we are ok with that? Or is not including whitespace/boundary-space an oversight in XQueryX? Need to clarify with Jim.
I am back to working on XQueryX, so I am looking at this issue, among others... I originally thought of doing what you describe, David. Unfortunately, there doesn't seem to be a way to encode boundary-space declarations in XQueryX, which means that the meaning of XQuery is lost after one converstion to XQueryX and back to XQuery with the stylesheet (since the declarations are gone in the final XQuery, the spaces will be stripped on subsequent XQueryX conversions). I guess we are ok with that? Or is not including whitespace/boundary-space an oversight in XQueryX? Need to clarify with Jim.
> Unfortunately, there doesn't seem to be a way to encode > boundary-space declarations in XQueryX, That is deliberate, the declaration was removed see bug #2288. There is no need for a boundary space declaration in xqx as there is no way to generate boundary space, the xqueryx.xsl stylesheet never generates boundary spaces. > which means that the meaning of XQuery is lost after one > converstion to XQueryX and back to XQuery with the stylesheet No not at all. With the change I proposed, the meaning of the query is preserved. > , the spaces will be stripped on subsequent XQueryX conversions). No they will not be stripped. The point of the proposed change is to encode the spaces as a string literal, these are never stipped or affected by boundary space declarations. David
(In reply to comment #5) > > Unfortunately, there doesn't seem to be a way to encode > > boundary-space declarations in XQueryX, > > That is deliberate, the declaration was removed see bug #2288. > There is no need for a boundary space declaration in xqx as there is no way to > generate boundary space, the xqueryx.xsl stylesheet never generates boundary > spaces. > > > which means that the meaning of XQuery is lost after one > > converstion to XQueryX and back to XQuery with the stylesheet > > No not at all. With the change I proposed, the meaning of the query is > preserved. > > > , the spaces will be stripped on subsequent XQueryX conversions). > > No they will not be stripped. The point of the proposed change is to encode the > spaces as a string literal, these are never stipped or affected by boundary > space declarations. > > David > Didn't look at your suggestion carefully - yes, I think encoding as a string literal would work... will do that.
Constr-ws-tag-6.xqx is still unchanged in the zip file checked in to cvs with log entry: XQueryX.zip for XQTS release 1.0.1 will these be fixed before any 1.01 release? David