RE: attribute order (RE: Syntax Sugar and XML information models)

[Gavin Thomas Nicol <gtn@ebt.com>]

Christopher R. Maden [mailto:crism@maden.org]
> The attribute-element dichotomy developed precisely to model the
> human model of short, named qualities of an object vs. the contents of the
> object themselves.

...or components with simple type vs components with complex type. This

 struct {
   int foo;
   struct {
     int foo;
   } bar;
 } doc;

roughly corresponds to this

 <doc foo="1"><bar foo="2"/></doc>

> So it seems clear to me - if you want order, use elements.  If you use
> attributes, you don't get order.  No arguments.

I don't think ordering is important. It is the structured vs.
unstructured nature that should make one an attribute and the
other an element. Ordering is really just an additional type
constraint.

One design goal in XEXPR was to unify this. If you look at

  <print x="4"/>

and

  <print><set name="x"><add>2 2</add></print>

the only real difference is that the second is more highly
structured, but in XEXPR, they are equivalent. This makes
XEXPR *much* more usable than it otherwise would be (not
that I commend it for personal programming ;-)).

> The infoset should, IMO, represent the conceptual *information* of a
> document - no attribute order, no CDATA marked sections, no numeric
> character references.  (General entities are a bit of a toss-up.)  But
> given that, basing an editor strictly on the infoset seems like a silly
> idea, since some of those things are interesting to an editor.

Right, and I think that is the main point. Different kinds of
applications need different sets of information. This has been
recognised for a very long time (propertys sets, DSSSL etc. have
something of this notion).