OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] UTF-8+names

[ Lists Home | Date Index | Thread Index ]

davidc@nag.co.uk (David Carlisle) writes:
>> What are existing processors supposed to do?  
>It's just another encoding, so they'll do whatever they do if they get
>something in some encoding that they don't know about: Terminate with a
>fatal error. The main thing this has going for it is that
>architecturally there is nothing new here at all, it is just yet
>another variable length Unicode encoding.
>Of course it's cunningly designed to look like an architectural change,
>that allows such syntax as: <&eacute;/>, but really specifying this
>encoding should be no more problematic than specifying iso-8869-1
>either encoding may or may not be supported by popular parsers, but
>either way it doesn't really imply any change to the processing model.

I don't know about this.  I have to say that it feel fundamentally
corrupt to me, effectively cheating on the separation between character
encodings and the representation of characters in those encodings. 

That is therefore an enormous processing model change.  This is way
beyond surrogates. The potential for further disruption on this
precedent seems downright boundless.

I wrote a piece on XML as a disruptive technology a few years ago [1],
but I can't say I expected XML to drill into the Unicode layer and
modify the very notion of a character encoding.  On the other hand, the
XML specification process for the last few years seems to have focused
on setting dangerous precedents, so perhaps this was inevitable.

Here I thought putting namespace prefixes on entities was a cheap hack.
I lacked imagination.

[1] - http://www.xml.com/pub/a/2000/06/21/disruption/index.html 


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

Copyright 2001 XML.org. This site is hosted by OASIS