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] [off-topic] xtext -- encoding declarations for text

[ Lists Home | Date Index | Thread Index ]

From: "Richard Tobin" <richard@cogsci.ed.ac.uk>

> If something like this is used, I *strongly* recommend limiting it to
> a single line - unlike the XML declaration.  The possibility of
> multi-line declarations is an annoying complication when there is the
> possibility of line breaks that depend on the ncoding, as in XML 1.1.


> The declaration should be readable based only on the character set
> knowledge that can be gleaned from the first few characters (e.g. that
> it's a superset of ascii, or that it's a variant of ebcdic).
> Also, the fact that the first few characters depend on the application
> will make it hard to write general transcoders.

I had thought that too, but on thinking about it more I cannot see any 
additional complexity compared with the XML Appendix F.  The details 
of the algorithm are different but still it is the same three steps

 * look for BOM or zero-patterns (for charsize and endianness)
 * else look for EBCDIC/ASCII signature (use string "[^a-zA-Z01-9]{1-4}xtext\b" 
    rather than "<?xml\b"
 * read rest of line forward until "encoding" and its literal

Murata-san had mentioned on W3C TAG an idea for using CSS's @ for 
a general text encoding header, but the big stumbling block with any fixed
delimiter is that it will only work on some text formats, and will break 
existing parsers.  Which is why I think it is important to check that
some delimiter was used, but equally important to allow any delimiter.

Rick Jelliffe


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

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