[JDEV] Protocol bits and discussion
Robert La Quey
robertl1 at home.com
Wed Jun 2 17:22:51 CDT 1999
At 04:32 PM 6/2/99 -0500, you wrote:
>A kind of general rule of thumb is that you wrap "core data" with tags,
>and you place any optional attributes of that core data in attributes. So
>the core data of every packet is a sub-tag, and any attributes of that
>data is described with attributes in those tags.
>Right now there aren't many attributes, but as more is demanded of Jabber
>I'd expect that more optional attributes will pop up over time(for example
><icon src='http://asdf/mystatus.gif'>away</icon> might be a future
>Does this make sense?
Sort of but it still seems pretty arbitry.
Let's take another tack. Your example extending the <pass> tag
leads me into the following thoughts.
Parsing the XML naturally leads to a tree. Attributes
reside at the nodes of the tree. Nesting rules lead us
up and down the tree.
If I expect a node of the tree might be extended by
adding a sub tree then I should use a tag. If not use
>In Jabber's case, there are a few good reasons to structure it as it is:
>at some point in the future the protocol might expand in unforseen ways,
>say you wanted to support a special type of password that was incompatible
>with anything else, you could easily:
> <pass type='test'>test</pass>
>So that all of the "old" servers and clients would simply ignore the new
>optional type='' attribute. It works out much more cleanly with the
needs a tag because you perceive passwords as extensible.
This could be dealt with by using attributes of <login>
e.g one could have an associative array of attributes
indexed by the first key="whatever". I do agree it is
more natural and cleaner to express pass as a <pass> tag.
Still it is less than obvious to me that we have a really
good design rule for determining what is a tag and what is
a waht is an attribute.
Now note though that it is quite possible that none of
us is going to do a good job of predicting the future.
A mechanism for evolving XML systems is needed, i.e.
Mapping JABBER V 1.0 => JABBER V 2.0 where the actual
tags are different form V 1.0 to V 2.0. Maybe one
wants to do this on the flie. It does not appear to be
too dificult but the devil may lie in the details.
More information about the JDev