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: XML Blueberry

I'd like to suggest a different way to bring in NEL and some of the other
proposed changes without it being quite so damaging to interchangability and
the current crop of tools.  Instead of  changing the version in the xml
declaration, change the encoding.  The Rec would allow a new encoding
(probably several to cover 8- and 16- bit versions). A processor could
ignore the document if it did not understand the new encoding, or try to
handle it anyway.

This wouldn't address getting the new characters into names, but it seems
pretty clear that many (most?) of the posters on the list don't think that's
vital anyway.  So we might have

<?xml version="1.0" encoding="utf-8-nel-3"?> or something of the sort.

Seems to me that this would be the least damaging, most understandable way
to bring in the changes, if we leave names as they are now.  And, after all,
the NEL problem ***is*** one of encoding - how we encode a <newline>


Tom P

[Tim Bray]
> But the costs seem pretty darn high to me.  If Blueberry
> is adopted and is given a new <?xml version number, this
> means that the mass of already-deployed XML software will
> correctly throw such data on the ground, at some considerable
> cost to interoperability.  If there is no <?xml version
> number, then such software will try to read it but then
> unpredictably throw it on the ground upon encountering the
> first NEL that appears inside a tag - or the first
> element-type/attribute-name using one of the non-XML-1.0
> name characters.  Of these two, the second problem seems more
> damaging, so I'd argue pretty strongly for signaling
> Blueberry documents with some value of <?xml version="X" ?>
> where X is not "1.0".
> And the cost of this is very high.  At the moment, XML 1.0
> is pretty effectively one thing and just one thing, and if
> I claim to ship out XML and you claim to be able to read it,
> we can usually interoperate, especially since we're both
> probably using expat or xerces or msxml.  Introducing
> Blueberry will impair this admirable simplicity.