[JDEV] XML stream parsing in Java

[arh14 at cornell.edu]

(Apologies for losing track of the original authors)

> > I know that there was some difficulty finding an XML parser in Java that
> > didn't require the full document (it wouldn't process a "stream" on the
> > fly), so some work has gone into writing a streaming parser around the
> > internal tokenizer of the XT parser.  Ask on the java-dev list for more
> > info...

Sun's XML project's parser which (or will be) a standard extension to the 
runtime library can parse an InputStream.  Sun's parser is also the one 
reviewed as most compliant on XML.com.

> You might have the following:
> 
> [packet type byte]
> [1-2 other fixed bytes]
> [4 bytes-from ID]
> [4 bytes-to ID]
> [data length byte]
> Subject: Here's a subject of you want one.
> Who needs threads?  I just want to send my buddy at message! :-)
> Here you can have all kinds of XML (or HTML) attributes, fonts, etc...
> asdgf asdfkjasgoijqwert asdgaldgjkas
> <NULL>

And with a fixed format, packet-based system, what would happen if you 
made an addition to the format, e.g., a new field?  Since Jabber's goal 
was to be a universal transport bridging many other local 
protocols/formats, Jabber must be flexible.  XML will handle this 
scenario nicely (the client will just ignore the addition), and clients 
will not have to be changed.

Also, could you for instance, save all the messages in a database and 
execute queries against them?  Again with XML this is very easy...you can 
even use XQL (eXtensible Query Langauge I think, SQL counterpart in the 
XML world).

> I think it's funny every time I read how XML is "totally expandable" on
> the one hand, and "standardized" on the other hand.  Since the client has
> to deal with new tags as the server guys come up with more makes me think
> that it's harder to impliment.

No the client doesn't have to.  Just like Netscape 2 doesn't know what 
<applet> tags are, but it still works.


Aaron