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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: How best to represent unrepresentable characters in NAME tokens?

[ Lists Home | Date Index | Thread Index ]
  • From: "Rick Jelliffe" <ricko@allette.com.au>
  • To: "Andrew Greene" <agreene@bitstream.com>, <xml-dev@ic.ac.uk>
  • Date: Wed, 5 Nov 1997 01:44:29 +1100


 
> From: Andrew Greene <agreene@bitstream.com>

> * Is there a need for a "semi-standard" solution to this problem, or am
>   I the only one struggling with it?
> 
> * Is there interest in adopting some variation of number 2 so that we're
>   better able to exchange such data?
> 
> * I can't help but think that number 3 would be the most elegant solution
>   if it were only legal. Yet I'm also sure that the XML committee had a 
>   good reason for disallowing it. I'd be interested in hearing what their
>   reason was, so that I may become enlightened. :-)

When I proposed the "native language markup" scheme (for the ERCS project of
the Standardization Project Regarding East Asian Documents of the China/Japan/
Korea Document Processing Group) which XML implements, we also developed
the idea of "lowest-common-denominator naming".  

This means that you should only use characters in names which are available
in all the systems through which the document will pass.  So, if you have
a requirement (known upfront) to save in ASCII, then you should use "ue" not
"u umlaut".   The best solution is to not create one in the first place!
(For example, Japanese users should restrict themselves to only using 
characters in Shift JIS for names, not in JIS 212 or the additional sets coming.)

I do not think there is any requirement for global interoperability of 
DTDs: if there is, then some system of numeric character references in 
names would be appropriate.   

However, I can suggest a 4th approach that may be better than your three.
It is to provide a language or encoding specific fixed attribute, giving
the ASCII form of the GI for use in dumping.  OF course, it requires a
minimum of smarts to convert to the new IDs.  You might have an "also known
as" aka attribute (I'll use B instead of esszet):

<!ATTLIST  straBe
	aka CDATA #FIXED "en-646 street de-8859-1 straBe de-646 strasse" >


Rick Jelliffe

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

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

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