Re: Closing Blueberry

[Rob Lugt <roblugt@elcel.com>]

Richard Tobin wrote

> >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.
>

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.

~Rob