[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Parsing Streaming XML Incrementally

• To: Bob Hutchison <hutch@x...>
• Subject: Re: Parsing Streaming XML Incrementally
• From: Development Role Account <dev@n...>
• Date: Thu, 15 Nov 2001 08:17:04 -0800 (PST)
• Cc: Development Role Account <dev@n...>, <xml-dev@l...>
• In-reply-to: <B81929EE.279E%hutch@x...>

On Thu, 15 Nov 2001, Bob Hutchison wrote:

> Hi Stephen,
>
> Does the total information sent by the client to the server make a
> well-formed XML document? Same for the total information from the server to
> the client? From your example it looks as though it might.

Yes, in both directions. The client could emit:

<?xml version="1.0" encoding="us-ascii"?>
<handshake version="1.0" foo="bar" other_params="blah">
  <request request-id="blah blah">
    <!-- tags which indicate the type and parameters of the request -->
  </request>
  <request>
    <end-session/>
  </request>
</handshake>

in one fell swoop, and the server replies, in one fell swoop:

<?xml version="1.0" encoding="us-ascii"?>
<handshake version="1.0" foo="bar" other_params="blah">
  <response request-id="blah blah">
    <!-- content tags indicating status of response and requested info -->
  </response>
  <response>
    <session-ended/>
  </response>
</handshake>

However, while this approach is effective for simple transactions, it does
not allow the conditional behavior which my reading of the protocol spec
seems to indicate is possible (and even required for certain exchanges).

> If it does, then I'm willing to bet that the vendor is expecting you to open
> one connection/stream for each direction. You write XML in pieces to the one
> and read it back from the other.

I'm not following you at all here. It is a TCP socket, so it is already
bi-directional. You can read and write to it at will (within the
limitations of your chosen I/O model, of course ... blocking,
non-blocking, select() multiplexed, etc.). There is no way to open another
stream - if you did you would have a completely distinct session (like
with an HTTP server, for example: if you make multiple connections the
server forks separate processes/threads which are completely separate
from each other). I/O is not the issue here ...

> Don't close the stream from the server (actually either stream). If you do
> this then an event based parser like SAX will call a handler/call-back for
> each event it receives. If you write your request pieces from the handler
> methods, then you should get an interleaved protocol going.

The client code is already structured in that manner. There is a
state machine, and whenever data is received from the server it is parsed,
and client emits an appropriate response according to what it has received
and what state it is in.

> If you close the connections, or try to use a parser that has to read ahead
> you will have a problem. (So don't generate a DOM).

It is not a SAX/DOM issue either - at least for all of the perl parsers
I've been using, both SAX and DOM models expect a well-formed document ...
SAX parsers will respond to XML tags as they are encountered, but if
closing tags are not seen after the complete document has been scanned,
the parser croaks. The problem being that none of the "documents" emitted
by the server are complete ... but the client still needs to react to
the XML fragments.

> Just a guess. I hope I said it clearly enough to be understood.

Thanks - try again :)

-sjs

• Follow-Ups:
  • Re: Parsing Streaming XML Incrementally
    • From: Geert Bormans <geert.bormans@a...>
  • Re: Parsing Streaming XML Incrementally
    • From: Bob Hutchison <hutch@x...>

• References:
  • Re: Parsing Streaming XML Incrementally
    • From: Bob Hutchison <hutch@x...>

• Prev by Date: Mobile XML Databases and Synchronization
• Next by Date: Re: Regarding XML support for Netscape
• Previous by thread: Re: Parsing Streaming XML Incrementally
• Next by thread: Re: Parsing Streaming XML Incrementally
• Index(es):
  • Date
  • Thread