xml-dev - Character streams vs. Byte Streams

["Michael Kay" <M.H.Kay@eng.icl.co.uk>]

James Clark:
>This is fine except that it should use byte streams not character
>streams.  What you get if you are reading from the net or from an
>archive or a database or whatever is bytes not characters...

I have enormous respect for James's arguments as always but on this one I
beg to disagree. The reason I have asked for support for character streams
is so that the parser can process not only stuff stored on disc but *the
output of another program*. For  example, I have an application where the
XML document is constructed as the result of an SQL query that pulls
together fragments of XML stored in different places in a database. The SQL
query, like most other programs I use and write, prefers  to output
characters rather than bytes. That, after all, is the reason XML was
designed to be human-readable.

And I have to say that in my experience so far, the parsers are so lightning
fast compared with the  application that generates the XML or consumes it,
that an argument based on saving microseconds will not sway me much.

I don't think there is a real problem with the XML spec. This defines the
syntax of XML in terms of characters. It requires the parser to accept
certain encodings of the character stream as a byte stream, but it permits
the parser to accept other encodings and therefore by implication to
delegate the decoding of the byte stream to another object in the  system.
In fact it explicitly recognises that an "external transport protocol" might
have a say in the matter, and that is a term we could interpret very widely.

Regards, Mike Kay, ICL



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)