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

Vincent-Olivier Arsenault wrote:

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

I think we anticipate a fixed set of rules, very close to the rules
in the XML 1.0 document, and then: whatever Unicode says is in, is in,
and whatever is out, is out.

But in full generality that means each document has to bear the
version number of Unicode that it assumes (for its names only, of
of course, not for its character content).  That means a series of
updates to parsers are required, and control of the schedule is
lost from W3C to Unicode.  Is this a Good Thing or a Bad Thing?

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

Just so.

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

Some parsers, at least, have their own tables.

> Even if they are not, they should, 

That's dangerous: it leads to interop failures.  What if the version of
Java at the receiving end has slightly different tables from the one
at the sending end?

But that point has to do with *implementation*, not specification.

There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein