[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

question about incremental processing



Section 4.10 of draft-hollenbeck-ietf-xml-guidelines-04 states the
following:

   In some situations, it is possible to incrementally process an XML
   document as each tag is received; this is analogous to the process by
   which browsers incrementally render HTML pages as they are received.
   Note that incremental processing is difficult to implement if
   interspersed across multiple interactions.  In other words, if a
   protocol requires incremental processing across both directions of a
   bidirectional stream, then it may place significant burden on
   protocol implementers.

I'm curious to learn the motivation and rationale behind this statement.
What kind of applications did you have in mind? The reason I ask is that
in the Jabber world we use bidirectional XML streams to transmit XML
fragments. These fragments or "chunks" (note: these are not XML Fragments
as defined by http://www.w3.org/TR/xml-fragment) are incrementally
processed for the purpose of presenting presence information, text
messages, and request/response interfaces in the context of Instant
Messaging (IM) and other near-real-time messaging applications. However,
we don't find that such incremental processing places an especially heavy
burden on protocol implementers. In fact, there are numerous server and
client implementations of the Jabber protocol in existence today, for
platforms as diverse as various Unices, Windows, MacOS, BeOS, Java, and
wireless devices. I'd appreciate it if you could explain your thinking
here so that someone from the Jabber project can provide evidence to the
contrary. :)

(Part of the issue here may be that Jabber implementations do not
incrementally render an XML document as implied by the analogy of a web
browser incrementally rendering an HTML document. Rather, the "document"
in Jabber is a complete session of a client on a server, and each XML
"chunk" is one snippet of the communication between the client and the
server, for example a message or presence update received from another
Jabber user. Perhaps this stream-centric or session-centric viewpoint is
sufficiently different from the document-centric viewpoint prevalent in
the XML world to cause confusion regarding the relative difficulty of
implementation.)

Thanks for your time -- overall I think your document will make a great
BCP.

Peter

P.S. For details regarding the Jabber protocol and its use of XML, refer
to http://www.jabber.org/ietf/ (initial I-D submitted 2002-02-21, with
more focused I-Ds on the way).

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.html