This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
K-NumericDivide-37 K-NumericIntegerDivide-43 K-NumericMod-22 I believe the XQuery spec allows such queries in which there isn't any whitespace between the integer and the keyword (as in 10div 3). The text I believe is the following in [A.2.2 Terminal Delimitation]: << It is customary to separate consecutive terminal symbols by whitespace and Comments, but this is required only when otherwise two non-delimiting symbols would be adjacent to each other. There are two exceptions to this, that of "." and "-", which do require a symbol separator if they follow a QName or NCName. >> - Jerome
Hello Jerome, See A.2.4 Whitespace Rules, in particular the bullet point list of examples. It reads: * "10div 3 results in a syntax error." I think the tests are consistent with the specification in this matter(but the specification can be wrong, on the other hand). Would closing this bug as INVALID be an acceptable resolution for you? Frans
I think I would like a clarification here. I am not sure why the rule I point out does not apply in this case. Or maybe I misunderstood the rule? You point to some examples in the whitespace section, but I am not sure I understand from the rest of the spec why those examples should be syntax errors. - Jerome
I'm not sure if I'm right here, but nevertheless: According to A.2.2 Terminal Delimitation, "10div 3" consists of these terminals: * "10", non-delimiting terminal symbol * "div", non-delimiting terminal symbol * " ", symbol separator * "3", non-delimiting terminal symbol Further, "It is customary to separate consecutive terminal symbols by whitespace and Comments, but this is required only when otherwise two non-delimiting symbols would be adjacent to each other." Hence, "10" followed by "div" is two adjacent non-delimiting symbols. I think the key is that "10" isn't a delimiting terminal. I agree that "10div 3" is possible to parse. I don't know why it is like this. It might be that it in other cases would cause trouble if digits were delimiting. It could also have to do with XPath 1.0 compatibility, although after a glance at the spec I couldn't find support for this. I would with interest read a thread on w3c-xml-query-wg@w3.org about this, or Scott Boag could be asked to comment on this report. I think this needs to be done: * Be made clear whether the tests are correct or wrong compared to the specification, and continue discussion or resolve this report appropriately * Consider whether a report should be opened on the spec for this syntax discussion (I can't motivate fully why "10div 3" is a syntax error, but I can accept it, and hence think the tests are ok.) Frans
(In reply to comment #3) > It could also have to do with XPath 1.0 compatibility, although > after a glance at the spec I couldn't find support for this. It's not for xpath1 compatibility, xpath1 would parse 10div 3, the fact that this is an error in xpath 2, even in BC mode is noted in http://www.w3.org/TR/xpath20/#id-incompat-in-true-mode (item 3)
For documentation purpose: I was told how whitespace is handled was decided here(member only link): http://lists.w3.org/Archives/Member/w3c-xsl-query/2005Mar/0070 Jerome, I'm resolving this bug with resolution INVALID since it appears to me clear that the tests conforms to the specs. If this is an acceptable resolution to you, feel free to change status to CLOSED. Frans
Assuming that the resolution is acceptable for the reporter; changing status to CLOSED.