XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Ten Years Later - XML 1.0 Fifth Edition?

Liam Quin wrote:
> On Wed, Feb 20, 2008 at 10:00:45AM +1100, Rick Jelliffe wrote:
>   
>> Ten years ago, or five years ago, or last year, the W3C Core WG should 
>> have said:
>>  * An XML processor should not attempt to process a document with a 
>> higher major version number but report an error.
>>  * An XML processor should attempt to process a document with a higher 
>> version minor version than the XML processor was designed for; In such a 
>> case, well-formedness error reports should note that the error may be 
>> due to changes in the minor XML version (parsers should note which minor 
>> version they are using when reporting that a document is well-formed.)
>>     
>
> 10 years ago that's more or less what was said; 5 years ago (I think, I
> forget exactly) the decision was reversed in a mistake that's one of
> the biggest reasons that XML 1.1 failed.
>   
But the policy never made it into the spec, did it?
>> 2) A coarse-grain sieve for fatal reportable name character errors
>>     * Strict and detailed rules for Unicode < U+0100
>>     * For U+0100 to U+FFFF include or exclude characters based on 
>> allowing or disallowing blocks (7bit ranges) which allows very efficient 
>> name checking with a 512 entry table and a mask. (This is perhaps more 
>> coarse-grain than even the 5th Edition!)
>>     * For characters not in the BMP (or surrogates) either allow or 
>> disallow indiscriminately all in names
>>     
> that's close to what 5th edition proposes.
>   
But it has the advantage of being easy to compute in two small lookup 
tables. The current 5th edition needs more processing an logic. If we 
want to help people make bad and obuscated documents, we may as well 
also at least have some speed justification.

>>  3) A fine-grain sieve for non-fatal optionally-reportable name 
>> character errors:
>>    These are the detailed rules.
>>     
>
> If it's not fatal and you don't have to report it, it's not an error.
>   
No. It is a formal error but one which is discretionary for every 
implementation to report. The implementation still would report that the 
chance of the false negative or false positive in the particular case of 
a mismatched document: the user could always select that they didn't 
want to accept documents with a different minor version if they thought 
there was some risk. The gain is that we would get a workable versioning 
system, and XML could start to evolve in little ways with minimal harm.
>> 4) Deprecate C1 controls
>>     
> I pushed hard for this in XML 1.1 and it's one of the reasons that
> XML 1.1 failed.  It meant that there were XML 1.0 documents that
> were not well-formed XML 1.1 docuemnts, and for some people that's
> a killer.  Or it was presented to me as a show-stopper at least.
>   
I don't believe that is the real reason it failed. That a handful of 
people had crappy mislabelled data that had previously escaped 
detection, and this was now being pointed out to them, or who wanted to 
have private characters but not use the PUA area, or wanted to re-use 
the control points as data rather than controls, are rare niche cases 
that probably deserve to be unsupported.

XML 1.1 failed because there was a compelling reason not to use it (the 
".1" making parsers fail) and because it didn't offer any relevant new 
features for users. 

Cheers
Rick Jelliffe


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS