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

Historical I18n Note

• From: Tim Bray <tbray@t...>
• To: xml-dev@l...
• Date: Mon, 16 Jul 2001 10:44:39 -0700

At 08:16 AM 16/07/01 -0500, Bullard, Claude L (Len) wrote:
>This is easy.  SGML preserves options using the SGML 
>Declaration.  The options have costs and require skill 
>to handle.  XML is simpler but it removes the options. 
>In SGML, Blueberry is a non-issue

Sorry, Len has now said this about 8 times and just for
reasons of historical accuracy, I have to make the point
that i18n in the SGML context was not quite the bundle
of sweetness-and-light that's presented here.  Anyone
who's ever tried to 

(a) understand what an SDATA entity is, and/or
(b) take a file full of them produced by Vendor A and
    try to figure out how to get them rendered on screen
    or paper by software from another vendor

will know what I'm talking about.  SGML handles these 
issues *in principle* fully & completely by abstracting 
away the notion of a character.  SGML handled a lot of 
issues in principle.  XML's decision to say "a character 
is an atomic unit of text as defined by Unicode, and you
have to support at least these 2 bit encodings" has less
abstract beauty but it's there for a reason, and it buys 
a huge amount of real-world interoperability that no 
previous markup-language system, including SGML, ever 
came close to. -Tim

• References:
  • RE: Two different sets of experiences about non-English identifie rs
    • From: "Bullard, Claude L (Len)" <clbullar@i...>

• Prev by Date: Re: Well-formed Blueberry
• Next by Date: RE: Conversion of XDR and XSD
• Previous by thread: RE: Two different sets of experiences about non-English identifie rs
• Next by thread: RE: Two different sets of experiences about non-English identifie rs
• Index(es):
  • Date
  • Thread