Streaming XML and SAX

Tom Harding tomh at
Sat Feb 27 16:50:42 GMT 1999

David Megginson wrote:

> Tom Harding writes:
>  > What bit sequence would you use as a separator and how would you
>  > ensure that no conceivable encoding would produce it spuriously?
> I'm talking about characters, not bit sequences.  For a simple
> solution, you should provide the entire stream in the same character
> encoding (remember that a transport protocol is allowed to override
> the encoding in the XML declaration or encoding declaration).
> Otherwise, the packets will need to be escaped somehow.

How?  You would doubtless agree that mandating a specific encoding for all streams sidesteps
one of the major benefits of XML.  Introducing an encoding declaration mechanism into the
transport protocol, as HTTP does, would duplicate the function of the XML processor.  But if
you have a specific solution that I've missed then I'm sure I can appreciate it.

> No, it still looks like a messy architecture to me, because the
> transport layer has to know about the packets -- it has to parse the
> XML about to get information about what it's looking at, and that adds
> complexity and inefficiency.  A clean architecture should separate the
> layers completely, and use XML only where it has an obvious advantage
> over other approaches.

It's amazing how two people can see things so differently.  I think it's supremely elegant
that only the XML processor needs to look at data coming off the wire.  It's also as efficient
as it gets.  Of course the software architecture that handles the documents emitted must be
modular and extensible, but the task of parsing is done.

Tom Harding

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list