Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] reading an xml from a socket

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: John Cowan <cowan AT ccil.org>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] reading an xml from a socket
  • Date: Sat, 21 Oct 2006 21:50:32 -0700

On Oct 21, 2006, at 4:26 PM, John Cowan wrote:

Steve Loughran scripsit:

Also, ASCII 0 is a forbidden character in an XML document. So you
could write something that streams out a document and sticks a NUL at
the end. The reciepient relays everything to an XML parser (via a
special Reader), until that NUL gets received, at which point an
end-of-file should be signalled. Result: no need to determine the size
of the message.

Might be a non-issue, but to be precise: NUL may occur for encodings
other than ASCII and UTF-8.
In contrast, Consistent Overhead Byte Stuffing (COBS) provides
efficient, reliable, unambigous packet framing regardless of packet
content.

that's a good point. While NUL may be illegal character in an XML
document, it may not be illegal in an encoding. I duly corrected :)

Actually, you had it right the first time. The byte 0x00 may appear in
in an encoding such as UTF-16, but the character U+0000 cannot appear
in an XML document. So it would be straightforward to layer a specialized
Reader over a standard InputStreamReader that detects U+0000 and returns
end-of-input.


I, too, should've replaced "NUL" with "zero byte" :-).

Nonetheless, a zero *byte* as an unambigous end-of-document marker would work as long as only ASCII or UTF-8 are used. This would be much more straightforward, practical and efficient than to append, and scan for, an (encoded) *unicode character* U+0000, because, in the general case, the custom Reader would somehow have to implement the (non-trivial) XML rules for character encoding detection, also to find the encoded U+0000 marker.

In addition, as recently discussed in another thread on this mailing list, an XML parser/serializer tends to be more reliable and efficient if being passed a byte-oriented InputStream/OutputStream, rather than a character-oriented Reader/Writer.

But to put the discussion into perspective: Any reasonable higher level protocol defines a generic framing mechanism, thereby omitting the need to think about XML specific framing anyway.

Wolfgang.




Archive powered by MHonArc 2.6.24.

Top of Page