This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
For unrelated reasons, I was looking at test LocalNameFromQNameFunc018, which contains the line: declare default element namespace"http://www.example.com/QNameXSD"; This test is intended to succeed, and Saxon parses it successfully; but looking at the spec, it seems this isn't allowed. A2.2 (in XQuery) says: (a) The non-delimiting terminal symbols are: ... namespace, ... StringLiteral, ... (b) 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. Is there any good reason why StringLiteral is classified as a non-delimiting symbol? Am I correct in saying that as the spec stands, the above line should be a syntax error? There are other oddities in the list of non-delimiting symbols as well. For example, it includes Char. This suggests that in the production rule [159] CommentContents ::= (Char+ - (Char* ('(:' | ':)') Char*)) the Char tokens must be separated by whitespace, whereas of course the opposite is true. I think that symbols that are used only in ws:explicit rules have no place in this list. Also, the statement "There are two exceptions to this, that of "." and "-", which do require a symbol separator if they follow a QName or NCName" isn't quite complete: "." also requires a separator if it precedes or follows a numeric literal. I encountered this in XQuery, but it applies in principle to XPath also.
> Is there any good reason why StringLiteral is classified as a non-delimiting > symbol? Not that I can see. In fact, I think it's contradicts """ and "'" being delimiting characters. So, yes, I think this is a bug and should be fixed. > Am I correct in saying that as the spec stands, the above line should be a > syntax error? I would let it pass, given my statement above that there is a contradiction. >> There are other oddities in the list of non-delimiting symbols as well. For >> example, it includes Char. This suggests that in the production rule >> >> [159] CommentContents ::= (Char+ - (Char* ('(:' >| >> ':)') Char*)) >> >> the Char tokens must be separated by whitespace, whereas of course the >>opposite >> is true. I think that symbols that are used only in ws:explicit rules have no >> place in this list. I agree. >> "." also requires a separator if it precedes or follows a >> numeric literal. I agree.
Resolution accepted by WG.
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.