Re: [JDEV] Protocol bits and discussion

[Robert La Quey <robertl1@home.com>]

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
>possibility)
>
>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
an attribute. 

Your example:

>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:
>  <login>
>	<user>test</user>
>	<pass type='test'>test</pass>
>	<nick>test</nick>
>  </login>
>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
>current approach.
>

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. 

I dunno.