12 div-3

[michaelhkay]

Revisiting an old issue here: should 12 div-3 parse?

Under the new 4.0 tokenization rules, it certainly doesn't.

But under Michael Dyck's interpretation of the 3.1 rules, it does parse; and accordingly we made it parse in Saxon: see https://saxonica.plan.io/issues/2715 .

Michael D's reasoning is at

https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0037.html

He argued that the the longest token "consistent with the EBNF" is div (because div-3 is not consistent with the EBNF), and that the rule requiring a space between an NCName and a hyphen does not apply because div in this context is a keyword, not an NCName.

Specifically, in existing XPath processors, does it parse?

I'm going to defend the new rules in 4.0 here, in which tokenization is independent of syntactic context. I think that's a much clearer definition. But in the interests of full disclosure, the CG might like to note that this may be incompatible with the way some people have interpreted the 3.1 rules

Incidentally, removing the tweak that makes Saxon able to parse 12 div-3 doesn't break any test cases.

[ChristianGruen]

Specifically, in existing XPath processors, does it parse?

In our implementation, it doesn’t.

[ndw]

12 div-3 is the number 12 followed by the name div-3.

[benibela]

It does not parse in Xidel

Michael D's reasoning is at

https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0037.html

I'm reminded of Benito van der Zander's post in xquery-talk a while ago:

My post?? I am not sure I remember that

Perhaps these posts are the reason it is parsing less than it used to

[ChristianGruen]

My post?? I am not sure I remember that

Glad to hear. I didn’t remember my reply either :)

[michaelhkay]

I have added to PR #1313 a note explaining how this is changed from 3.1.

[michaelhkay]

Closing the issue as the PR has been merged.