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

Richard Tobin wrote

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

Oh, I see what you mean.  So even though the "S" production hasn't changed,
processors (that normalise late) are forced to change their implementation
of the "S" production or risk being non-conformant.  I don't think this is a
very honest change do you?  I would prefer the xml spec to be consistent
without hidden inferences like that.