Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@r...> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
|
