Re: XML Blueberry

[Vincent-Olivier Arsenault <vincent@neuro6.com>]

At 02:48 PM 6/21/01, you wrote:
>On 21 Jun 2001 13:26:31 -0400, John Cowan wrote:
> > I am not sure what "backwards incompatible" is supposed to mean
> > in this context.  Old parsers won't be able to read Blueberry
> > documents, that's true.  But nobody needs to write a Blueberry
> > document unless they wish to exploit Blueberry features.  And
> > upgrading parsers to Blueberry is intentionally trivial: it's basically
> > about expanding a few tables.
>
>It almost feels to me like those tables should be the responsibility of
>the Unicode folks (or some similarly lucky but separate intermediary
>with time on its hands) to maintain, and that some means of
>incorporating them by reference might have avoided this entire
>discussion.
>
>I guess that would make the layering of XML 1.0 on top of Unicode more
>explicit.


Absolutely!!!

This revision is indeed NECESSARY as (I think) XML should have a greater 
(if not complete) independence from any encoding specification and delegate 
it (all) to UNICODE. Thus, the key requirement to me would be (quoting from 
the June 20 WD requirement list) : "The working group shall consider the 
issue of future updates to Unicode."

As for the "they can write latin markup anyways" argument, I don't see how 
we could EVER discriminate ANY cultural particularity (even if they SEEM 
obsure to us or to so-called "experts", lets not repeat the rfc822 mistake) 
by denying to its adherents their ability to create markup in the way they 
want. Isn't it just as imposing your own line-ending method except on a 
cultural level? That is SOOO american.( Sorry, I had to say it ;-) )

The backward-compatibility argument just doesn't hold : I'd be curious to 
see how (or if) Java parsers (for instance) enforce the restricions to 
UNICODE as specified in the XML spec. Aren't they just relying on the Java 
platform to handle encoding? Even if they are not, they should, that kind 
of code redundancy would just be the perfect symptom to the overspecified XML.

Couldn't that also fix the IBM issue?

v