DOM name validity tests do not match current spec

[bwrrp]

The DOM standard currently contains the following:

To validate a qualifiedName, throw an InvalidCharacterError if qualifiedName does not match the Name or QName production.

The links in this segment refer to the fifth (current) edition of the XML specification. Compared to the fourth edition, this version has updated the Name and QName productions to accept more characters. However, the test cases (for example dom/nodes/Document-createElementNS.js) still seem to follow the fourth edition rules.

For example, "ெfoo" ("\u0BC6foo") is a valid Name (and QName) according to the fifth edition, but not according to the fourth. The tests expect that using it to create an element throws an InvalidCharacterError.

Both Chrome and Firefox seem to apply validation logic similar to the fourth edition, so I'm not sure if this should actually be considered an issue with the DOM spec?

As a side note, the text in the DOM standard could be clarified to emphasize that the error should be thrown if either production is not matched. It could be misinterpreted to indicate failing to match one production is ok as long as the other matches. The qualifiedName should be both a valid Name and a valid QName.

[jgraham]

@hsivonen @annevk

[annevk]

Interesting find. I think Chrome's XML parser actually does follow the fifth edition so that difference is rather weird. @domenic has been looking into removing this check altogether so maybe we should just wait on that happening.

[bwrrp]

While the current spec still performs validation against the QName production, it looks like these overly restrictive test cases have been fixed in #12202 to match the fifth edition rules.

As spec and tests are now aligned, I guess this can be closed? However, it looks like document.createElementNS(null, '\u0BC6foo') still throws in Chrome 88 (bug) as well as in Firefox (bug).

[annevk]

Thanks for following up @bwrrp! I'll close this. Unless Chrome or Firefox come up with a compelling reason to not align with the standard, I think keeping the standard as-is is best.