OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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

Re: [xml-dev] Parsing Streaming XML Incrementally




Stephen J. Scheck wrote:
>
> Unfortunately, the device uses XML in a way which seems very non-standard
> to me, although I must admit I am fairly new to XML. I am of a mind to go
> and scream at the vendor of this device for making the RPC mechanism work
> the way it does, but first I'd like some feedback to ensure that I'm on
> sound theoretical footing.
> 
> Here's a brief example of how an exchange with this thing works, so that
> I can explain the problems with it:
>
> [ explanation deleted ]
>
> [...], is there any precedence for the way the vendor is using XML
> streams in this manner? Is there anything else like this in common
> use/acceptance? How does the experienced XML development community
> feel about it? Is it a valid "use" of XML, or an "abuse"?

This sounds a lot like how Jabber works (http://www.jabber.org/),
which is certainly an _interesting_ use of XML.

A Jabber session consists of two complete XML documents,
one sent client-to-server and the other sent server-to-client.
Both documents are generated in streaming mode; outgoing
data can depend on data received earlier in the dialog, 
and vice versa.

It's a bit reminiscent of lazy I/O in earlier versions of Haskell,
where the main program had the rather counterintuitive type 

    main ::  [Response] -> [Request]

i.e., it takes a list of Responses as input and returns a list 
of Requests.

There are Perl libraries for Jabber -- see dev.jabber.org --
you might find something useful in there.


--Joe English

  jenglish@flightlab.com