[ODE] XODE -Attributes vs. elements

Fri Mar 19 17:15:00 MST 2004

On Fri, 2004-03-19 at 17:14, Jani Laakso wrote:
> William Denniss wrote:
> 
> >I have used attributes in many places - but I just figured that they
> >arn't suited for everything.  Visualisation wise, personally, if I see
> >an element with only a value and no child elements, I assume it is a
> >property of the parent element anyway.
> >  
> >
> I want to comment about this XML attributes vs. elements case as it 
> affects XODE definition bigtime!
> 
> This debate is a never ending story for all XML users but I suggest you 
> check more information e.g. from:
> http://www-106.ibm.com/developerworks/xml/library/x-eleatt.html?ca=dnt-59
> It's good stuff for starters..

hehe, yes this is an age old debate, and one I was hoping not to bring
that debate to this list - but I guess we need to get it out of the way
and it's too late now anyway ;)

> Simple summary:
> 1. attributes cannot contain any markup and they are _atomic_
> 2. elements are hierarchical and _extensible_
> 
> Generally speaking, attributes are somewhat faster and simpler to use 
> with SAX / DOM / XSLT (XPath), but I wouldn't use this of a design 
> factor. Put all atomic stuff in attributes but if there's a possibility 
> that the data in question needs to be extended someday or you are not 
> absolutely sure if it's really atomic, then put it into element.
> 
> I skimmed through xode.txt and here's my comments:
> -<box> can have only one atomic sizex,y,z, use attributes
> -<cylinder> can have only one atomic radius, use attributes
> -<body> can have only one atomic mass, use attributes
> These are all atomic 1 to 1 cases don't you agree?
> 
> About the visual side of the XODE definition:
> XODE defines quite technical data, mainly lot's of parameters for 
> objects if you will and less hierarchial structures but these too also, 
> so it tends to use quite a lot of attributes imho. I wouldn't bother 
> with the visual "issues" too much.

You and Nate agree on this.  I assume you are also suggesting to expand
things like torque out to "torquex", "torquey" etc...

I do prefer the visual look of the way it currently is, but I understand
these arguments.  I am happy to change it if the majority supports the
move.

> One more thing, I share my thoughts with the guy that reminded me of 
> <ext> tag's pitholes. Having
> <tag type="anything">
>   <!-- content anything -->
> </tag>
> should be avoided as much as possible. Sure people can add anything to 
> XML document if allowed but if we already know even some of the optional 
> tags that can be used with XODE, why not to define them properly so they 
> are consistent. Could optional tags like mesh-file-location and color be 
> defined also? IMHO it's better to define these examples than to leave 
> them as examples using universal <ext> element. If the definition is not 
> suitable for someone, then this someone can use the dreaded <ext> tag.

We could define these tags and mark their compliance level as SHOULD or
OPTIONAL (rather than MUST like for the rest of the tags).

The problem is that then we have just widened the domain of XODE. People
will say "if we're including colour - why not include feature X" etc. 
This is something we have been trying to avoid and the general sentiment
I have received seems to agree with this.

If you want it standardized - then I would prefer to see an "official"
extension Schema (possibly based on
http://tankammo.com/xode/xode-extensions.txt).  This way people could
advertise either "XODE compliant" or "XODE-SXT (Standard eXTensions)
compliant".  With the really nice feature that any valid XODE-SXT file
is also a valid XODE file.

What do you think of this idea?  So long as this "official extension
schema" only used <ext> tags - then it is cross compatable with XODE. 
The only difference than what we have now being that the extensions are
in a schema as opposed to a text file.

Currently XODE will need to be revised every time a new feature is added
to the ODE core which is fine, and necessary to keep XODE relevant.  I
don't want to release a revision every time someone thinks of a nice new
feature they want added (an extension schema on the other hand could be
revised every day for all I care)!

> Sorry that my comments are coming a bit late..

no probs

Cheers,

Will.

-- 
William Denniss - will@ http://tanksoftware.com/