[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Closing Blueberry

• From: Rob Lugt <roblugt@e...>
• To: Richard Tobin <richard@c...>
• Date: Fri, 20 Jul 2001 14:09:10 +0100

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

• Follow-Ups:
  • Re: Closing Blueberry
    • From: Richard Tobin <richard@c...>

• References:
  • Re: Closing Blueberry
    • From: Richard Tobin <richard@c...>

• Prev by Date: Re: Closing Blueberry
• Next by Date: RE: "closed groups" (was RE: Blueberry is not "closed")
• Previous by thread: Re: Closing Blueberry
• Next by thread: Re: Closing Blueberry
• Index(es):
  • Date
  • Thread