xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From amr.f.yas...@philips.com
Subject [sml-dev] Re: Attribute and Element
Date Fri, 19 May 2000 13:24:50 GMT
> 	The confusion I am having now is, should I put the Price (or
> ValidBefore) as an attribute of the Ticket or put it as an element under
> the Ticket. What is the difference, and what is the benefits?

  * unordered
  * non-nestable
  * usually implemented as an array or hash-table
  * a bit briefer
  * good for really short stuff (longer stuff gets ugly)
  * all attributes are delivered together as one
    unit in the SAX api.

  * ordered
  * nestable
  * usually implemented as a linked-list
  * a bit more verbose
  * good for longer stuff
  * elements are delivered seperately, sequentially
    in the sax api.

In general; I "religiously" stick to elements unless some
XML specification forces me to do otherwise.  The XPATH
is different for attribute vs element children; thus
changing can be painful.  Especially if one needs "more
structure" later on... ie, the ability to nest.

Hope this helps.


I forgot two other points. If you make it an attribute; then
you have both elements and attributes in your document.  If you
stick with just elements, you avoid one form of syntax.  IMHO,
when explaining the data to a manager, it's alot easier to avoid
the whole element/attribute question by leaving the attributes
out to begin with.  ;)

In general, for B2B markup... attributes aren't really
needed.  However, they *are* very valueable if you have
mixed content; like HTML.  Think "adverb".

  <body> this is mixed <font color="red">content </font></body>

Arguably (and long arguments indeed), color is on a
different 'plane' than font thus it requires a different
syntax so that it's value, "red" is not considered part
of the body's content.   This is easily made concrete by
looking at the XSLT string-value operator;  which
is loosely defined for an element as the concatination
of all text children.  Thus, the string-value of the <body>
above does not contain "red", but it does contain "content".

Once again, for B2B stuff... I don't think this makes
a ton of difference; but the differences (and resulting
confusion?) are strong enough to make me steer clear
of attributes when I can do so.


The other consideration is uniqueness (only one instance of a particular
attribute for any one element).

I would assess it thus:

   Elements: Up to schema designer
   Attributes: Must be unique

   Elements: Up to schema designer - APIs generally preserve order.
   Attributes: original spec does not say but most standard APIs
       will not guarantee to preserve order.

   Elements: yes
   Attributes: no

As Clark says - in raw terms you can do pretty much anything with elements
that you can do with attributes but not vice versa.

Many implementations and designers make all sorts of assumptions about
attributes vs elements which are not expressed in the XML spec and these
assumptions may not be explicit or even shared with others so you need to be

View raw message