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: Blueberry is not "closed" (was: Closing Blueberry)

Asked off list:

> . . . just *declaring* Blueberry -- and not
> using any new feature, that older tools won't be able to handle it?

We would hope so.

A parser designed for XML 1.0 will do one of several things:

The preferred response is that it should stop at the XML declaration and
say, "I don't know how to handle this." Or equivalent error message. The
reason this is preferred is that otherwise we increase the risk of passing
bad data around. Although this is the correct response, it does have the
potential to cause the undesirable interaction in the market that has been
mentioned elsewhere. I think the issue is not if, but when, and can it be
postponed long enough to let smaller players keep competing.

A less desirable response would be to ignore the declaration and proceed. If
there were in fact no real blueberriness, there would be no problems on that
doc. But these parsers have no defense from real blueberriness -- just choke
suddenly on an extension character or a NEL where whitespace should be, and
reject documents with complaints about syntax that may not be recognized by
the person who has to figure out why the document supposedly validated
somewhere else chokes his machinery.

The least desirable response would be that the parser would only reject text
known to be necessarily illegal in the combination of XML 1.0/UNICODE 2.0.
Why least desirable? Data integrity and adherence to
<strike>spec</strike>recommendation. Even if we now loosen the
recommendation up, there is no way the older parsers could have known what
the changed recommendation written four years later would specify. This kind
of parser might not complain where you would want it to, and it might
complain in a meaningless place. Guesswork in, guesswork out.