[
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.
Yes.
> 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.
Cheers
Rick Jelliffe
|
