- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 25 Jan 2006 10:03:38 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2710 ------- Additional Comments From davidc@nag.co.uk 2006-01-25 10:03 ------- (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
Received on Wednesday, 25 January 2006 10:03:42 UTC