There are also practical issues I guess. If you need to validate the do=
cument
with a DTD,
there is much more control available to control the content of subeleme=
nts. You
can
say that the parent element's content model allows this or that, or thi=
s, that
or the other,
etc...
With attributes, there is less flexibility. Each attribute is either th=
ere or
not. There is no
way to indicate that if you provide this one, you can't provide that on=
e, or if
these two
are present, then you can't have that one, or if this one is present, t=
hen that
one has to
also be present, and so on (at least there is no way that I know of :-)=
Beyond that I think its purely an issue of what works best for what you=
want to
do. And there
is sometimes an issue of readability and writeability if the documents =
are ever
dealt with
by actual humans <gasp> :-) Attributes with large values are kind of fu=
nky
(IMHO) to
make very readable, so I'd make any property that could have large valu=
es an
element
if all other things were equal (which of course they often aren't.)
Overall, I guess the best rule of thumb is that attributes should hold =
stuff
that either you
need to get to fast without wanting to iterate the sub elements, or whi=
ch
provide 'control
information' as you indicated, or which need to have ID/IDREF semantics=
enforced, or
that you might want to provide implicit defaults for, and probably some=
others
that
I can't think of :-)
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
roddey@us.ibm.com
=