OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Closing Blueberry



>My point was that currently xml processors may translate 0xD/0xA pairs into
>0xA either before parsing the input stream, or before passing the characters
>to the application, it doesn't matter which.  But if the new-line
>normalization rules remove characters that the S production doesn't allow,
>then it becomes significant because those [processors] doing the
>normalization after parsing will fail (well-formedness error) whereas those
>that don't will succeed.  This creates an interoperability problem because
>well-formedness becomes ambiguous.

My point was that given

 <a {NEL} foo="bar">

you list two possibilities:

 (1) NEL is converted to NL on input so the document is accepted
 (2) NEL is not converted on input, and the parser produces a well-
     formedness error.

Do both these parsers satisfy the XML line-ending rules (modified to
include NEL)?  That is, do they both return the same characters to the
application that would be returned if NEL was converted to NL on
input?

Clearly (1) does, since it actually *does* convert NEL to NL.  (2)
doesn't, since it doesn't return any characters to the application
at all!  (2) would not be a conforming implementation.

So the line-ending rules *force* the line-end characters to be treated
as if they were in S even if they aren't.

-- Richard