This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The DOM Level 3 LS tests: wellformed1 wellformed2 wellformed3 require that a DOMError be generated with a specific type string (wf-invalid-character[-in-node-name]). However the spec does not (IMO) require this. Other than the specific error types defined in the description of LSParser, no mention is given to what particular DOMErrors a parse failure should produce - "implementations are expected to raise implementation specific errors and warnings for any other error and warning cases such as [...] XML well-formedness errors" For example a parser might see "<h×2/>", parse the node name as "h" (correctly according to the XML Name production) and then complain that the next character "×" didn't match the expected space-or-attribute-or-end-of-element, a parsing error that doesn't correspond to wf-invalid-character-in-node-name. If non-well-formed documents should be required to generate any DOMErrors at parse-time at all, there is IMO little that the spec mandates can be asserted about them. Perhaps just 'there should be at least one DOMError with ERROR or FATAL_ERROR severity'.