[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [JDEV] Well-formed XML.
In case you missed it, you might want to check out the protocol
I'm currently working on integrating expat:
into the core lib and redoing any related XML parsing code to use it and
follow the protocol changes...
On Fri, 19 Feb 1999, Thomas Charron wrote:
> A bit of a dated reply, but I just imported all of the archives into my
> mail box.. Anyhow..
> The problem with most of the XML parsers currently out there is that they
> are for parsing an XML DOCUMENT, and NOT a XML Protocol packet.. This is
> the reason why it wants well formed XML to be contained in a single root
> element, becouse that's how it is supposed to work in a document centric
> view of XML data.
> The way this should be approached is to only send ONE <j></j> element to
> the parser at a time. In your solution below, you STILL have the problem of
> a single root element if you attempt to send more then one <jabber></jabber>
> packet to the engine. You are simply adding an additional level of elements
> that is not needed..
> In response to your last comment, everything wrapped in <j></j> for the
> exact reason you pointed out.. To provide a base level root element, being
> j. ;-P
> Thomas Charron
> United Parcel Service
> Northeast Region
> IE Software Developer
> "Moving at the speed of a T3 Trunk Line!"
> > -----Original Message-----
> > From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of
> > Jason Diamond
> > Sent: Thursday, January 21, 1999 3:24 PM
> > To: email@example.com
> > Subject: [JDEV] Well-formed XML.
> > Hi, I have another protocol related suggestion. I've been experimenting
> > with a Java client and have been using several of the major XML parsers
> > to test it out. Apparently, a well-formed XML document needs to have a
> > single root element. Much like the root <html><!-- everything else goes
> > here --></html> element in HTML. All of the parsers I've tried so far,
> > stopped parsing at the second <j> element. There are several ugly
> > workarounds but I think it would be much more conducive to our goals if
> > we could take any off the shelf XML parser and not have to modify it in
> > order to write a Jabber client. So, I propose that both the server and
> > client wrap all their messages in a root <jabber></jabber> element.
> > Attributes could be used to specify the client and protocol much like
> > the current <j type='connection'> element. Maybe something like this:
> > <jabber agent='Jabzilla v1.0' protocol='19990121'>
> > <j type='login'><user>foo</user><pass>bar</pass></j>
> > <!-- etc. -->
> > </jabber>
> > The end </jabber> element could be used to indicate that the server or
> > client is getting ready to close the connection. Comments? I'm in the
> > process of downloading Cygwin32 so that I can make the necessary changes
> > to the server to test it out.
> > Just out of curiosity, why are all the messages between client and
> > server wrapped in a <j type='foo'> element? Why not <login> or
> > <message>? If we used element names rather than attribute types to
> > distinguish the purpose of a message, we could create a DTD specifying
> > what elements are allowed to be nested in others. For example, <user>
> > and <pass> would only be allowed in a <login> element. I'm not proposing
> > that we validate the XML as it comes in from the server, but it could be
> > used as a specification. Much like EBNF is for more traditional
> > protocols. And who knows, maybe while implementing and debugging our
> > clients we could have it validate the XML as an aid to determine a
> > source of errors.
> > Bye,
> > Jason.