This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The stylesheet has <xsl:variable name="PRAGMA_BEGIN" select="'(# '"/> <xsl:variable name="PRAGMA_END" select="' #)'"/> which means that a space is inserted at the beginging and end of each pragma. The stylesheet also inserts a space between the name and pragmacontents. so the xqueryx <xqx:pragma> <xqx:pragmaName>a</xqx:pragmaName> <xqx:pragmaContents>b</xqx:pragmaContents> </xqx:pragma> is defined to mean the same as the xquery (# a b #) The EBNF for this expression is [66] Pragma ::= "(#" S? QName PragmaContents "#)" so the first space has no effect but both of the second two spaces end up being parsed as pragmacontent. Since the semantics of this are implementation defined, this may or may not have an effect. However whether or not a sytem treats them differently here is no XqueryX expression corresponding to xquery expressions which do not have space in pragmacontent, such as (#a+b#}{1} which is a valid Xquery with pragma with name a and content +b The final space is easy to fix, $PRAGMA_END should just be '#)' However the middle space is harder, I think that the best fix would be for the stylesheet to continue to insert a space between the name and content but the XQuery EBNF modified to [66] Pragma ::= "(#" S? QName (S PragmaContents)? "#)" so that if you have any contents, they have to be separated by white space from the name (which would make my (#a+b#} example above a syntax error) David
I agree that this is something that may or may not (and, IMHO, probably not) make a difference, but there is a possibility that some implementation may ascribe importance to a space at the end of pragmaContents. Based on that possibility, I have removed the space that is the first character of PRAGMA_END as you have suggested. The XML Query WG will consider the second part of your suggestion -- the modification of the EBNF for Pragma to require whitespace to precede any PragmaContents -- at its earliest opportunity. Until the XML Query WG has considered that proposal, I am leaving this bug unresolved.
(In reply to comment #1) > I agree that this is something that may or may not (and, IMHO, probably not) > make a difference, but there is a possibility that some implementation may > ascribe importance to a space at the end of pragmaContents. Based on that > possibility, I have removed the space that is the first character of PRAGMA_END > as you have suggested. > Thanks, In a sense I already have an application for which this made a difference (which is how I came to spot it:-) As a general sanity check I have tests that try to round trip expressions between xquery and xqueryx and these spaces meant that I couldn't get back to where I started. I agree that it's unlikely that any sane application that's actually executing code is likely to treat these spaces as significant, but (as I'm sure you know even better than me) the job of the specification is as much to specify what insane applications can or cannot attempt as it is to say what the normal process should be. If you do consider the EBNF change I think it would need to be a little different from what I suggested as in that form it is an ambiguous grammar, If there are multiple spaces at the start of pragma content the later ones could either be parsed as part of the S that I added or as the start of pragma content. I think you'd need the regexp for pragma content to explictly exclude the possibility of initial space. (Unless you can appeal to some global "longest match" rule that would force any space in that position to be parsed by the "S", not sure of the exact semantics you are using there) David
Thank you very much for your comments on this subject. After considerable discussion, the XML Query WG determined that the solution with the fewest problems was to simply require white space between the pragma name and the pragma contents. The principle consequences of this decision are 1)No pragma contents can actually start with white space (because it would be indistinguishable from the separating white space), 2)Some otherwise acceptible pragma text (e.g., (# A-name="A value"#) is invalid, and 3)It is possible to represent something in XQueryX that is not representable in XQuery. It is our conclusion that problem 1) will very likely not affect any existing XQuery implementations or users, that problem 2) will affect a small number of implementations or users, and that problem 3) is moot because XQueryX syntax that does not transform into correct XQuery syntax has no meaning and is thus incorrect. Based on your most recent comment (#2), we believe that we have completely resolved this comment and have marked it CLOSED. If you disagree, you are welcome to reopen the bug.
I am reopening this to ask for clarification on an issued raised by test extexpr-26: (bug #3151) http://www.w3.org/Bugs/Public/show_bug.cgi?id=3151 If the pragmaContents is empty, should the whitespace still be required after the QName? My interpretation of the resolution was that whitespace was needed only to separate the QName from the pragmaContents. The writer of this test seems to have interpreted it as meaning that the space is needed after the QName regardless what follows.
My memory of the discussions, and my interpretation of the wording in reply #3 below (which I wrote), is that the white space is required only to separate a pragma name from pragma contents, not that a pragma name is always to be followed by white space. Thus, I believe that (# Pname#) satisfies the intended syntax for pragmas as discussed and recorded in response #3. Of course, I do not believe that any harm is done when a space is used, based on my interpretation that whitespace immediately following a pragma name is not part of a pragma contents. Thus the pragma (# Pname#) and the pragma (# Pname #) are, IMHO, identical in semantics. As a consequence, I do not believe that this is actually an XQueryX bug, nor will a change to XQueryX have any effect on this issue. I am therefore transferring ownership of this bug to our grammar expert and editor.
Scott, when you answer this, please show us the new grammar productions.
I transferred this bug from XQueryX to XQuery on the grounds that any change to address it must apply to the XQuery grammar, and leaving it in XQueryX has not gotten it any attention. (Sorry, Don!)
(In reply to comment #7) I've tried to research the history of this. In the April 2006 telcon, http://lists.w3.org/Archives/Member/w3c-xsl-query/2006Feb/0030, the request was made to change the grammar to: [66] Pragma ::= "(#" S? QName (S PragmaContents)? "#)" Which I did. Mike Kay's comment (http://www.w3.org/Bugs/Public/show_bug.cgi?id=2710#c4) and subsequent comments seem to have been made after this grammar change, which is confusing to me since the grammar now clearly allows for there being no whitespace after the QName. extexpr-26 of XQTS 0.9.0 has: (# ns1:you-do-not-know-me-as-index#){fn:count((1,2,3))} The XQTSCatalog lists this as being a "runtime-error" (erronious in any case for a syntax issue!), and the test contains the comment "Negative for extension expression for new sytax (missing space after pragma name)". I think this is a bad test... the test clearly parses under the current grammar. So the answer to Mike's question "If the pragmaContents is empty, should the whitespace still be required after the QName?" is "no", whitespace is not required. I don't think any further clarification is needed in the spec. Perhaps this bug should be transfered as a bug on extexpr-26? Will wait for ratification of the WGs to close the bug.
All: extexpr-26, was changed to reflect this change and no longer is out of sync with the proposed Recs. I think this bug can be safely closed by David/Michael. I can close it as well. I am marking this as "fixed" Greetings, Carmelo