[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Blueberry

  • From: Vincent-Olivier Arsenault <vincent@n...>
  • To: xml-dev@l...
  • Date: Thu, 21 Jun 2001 17:52:53 -0400

Re: XML Blueberry
At 05:16 PM 6/21/01, you wrote:
>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).

But couldn't that be deduced from the binary representation (on the 
platform level) so that the parser just has to deal with a "current" (at 
the time of the parser implementation) UNICODE spec string? Why does the 
(XML) parser need to know the charset used?

>That means a series of
>updates to parsers are required, and control of the schedule is
>lost from W3C to Unicode.

I don't think it HAS to.

>Is this a Good Thing or a Bad Thing?

How can we determine this? I think the question roots to "what is XML"... ;-)




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


That's not XML interop but UNICODE interop. Aren't such "recovery" 
mechanism specified in UNICODE? And anyways the problem exists with 
implementations based on the current spec, you said it yourself : some 
parsers have tables and some don't. Interop failures are not bad if they 
are expected (which is not the case now  in XML). I suggest looking at the 
OSI layer model for inspiration, and to project UNICODE-XML 
interface+protocols onto it. Think abstraction!



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

I was just stating this as a SYMPTOM for bad design.

v


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.