XOM API for Processing XML with Java

["Steve Loughran" <steve.loughran AT gmail.com>]

On 20/10/06, Wolfgang Hoschek <wolfgang.hoschek AT mac.com> wrote:
> On Oct 20, 2006, at 12:42 PM, Steve Loughran wrote:
>
> > On 20/10/06, Wolfgang Hoschek <wolfgang.hoschek AT mac.com> wrote:
> >> XML does not specify an end-of-document marker. Instead, such framing
> >> issues are left to a higher level protocol (e.g. HTTP).
> >>
> >> A generic XML parser has no knowledge of the higher level protocol in
> >> use, thus will parse until it hits end-of-stream (EOS). For example,
> >> HTTP/MIME knows where the end of a response occurs, so an InputStream
> >> containing the XML payload derived from a servlet will indicate EOS
> >> at the correct spot. If you're not using a protocol that has framing
> >> built-in, you'll have to roll your own. Here's a simple example:
> >>
> >> msg := length payload
> >> length := 4 byte integer (big endian)
> >> payload := sequence of <length> bytes
> >>
> >> For are more thorough discussion of framing issues, see [1] and [2].
> >
> > You could also stick a version number/magic number at the start of the
> > communication. If the receipient does this it piggybacks on the TCP
> > ack packet and costs you nothing.
> >
> > 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 :)

As an aside, SOAP uses HTTP's own packaging options, which are,  'send
content-length header' or 'end the transmission after the message is
sent. The former requires you to know the message length in advance
(which forces you to buffer rather than stream XML to the socket), the
latter does not reliably distinguish between legitmate end of
transmission, and network failure. Fortunately, the XML parser picks
it up for you. That is, unless a proxy server gets involved...

-steve