[
Lists Home |
Date Index |
Thread Index
]
Ronald Kent Gibson wrote:
>
> Someone once told me that you should only used attributes when you know that
> you will never need another attribute. (Case 1)
>
> And then I read somewhere to forget about attributes except for the
> exception of an id attribute. (Case 2)
>
> Does anyone care to comment and clarify this.
The main rule is that there is no one rule. But two things are certain
1) Attribute values are strings and not markup, and
2) Any one element can only have one attribute of a given name.
Given 1, don't use attributes when the value is or might become
structured - unless you want to do your own parsing of the attribute
string, as in svg.
Given 2, use attributes for name/value pairs where there will not be
duplicate names (i.e., properties).
Another point is that the scope of attributes in an element can be taken
to be the entire element - because there is no way to specify that they
would apply to any particular child element - so many people consider
that an attribute should contain data about the element itself. I think
that is sound, but it is easy to go the next step and declare that
attributes should _only_ hold data about the element and _not_ data per se.
That is going too far, I think. Consider a lookup table -
<item original='road-kill' translation='Road Kill'/>
This task is very well-suited for an all-attributes approach and is
economic besides. In general, row-like data consisting of simple
name/value pairs can be well modeled by an attribute-only approach and
is more compact and (I think) easier to read than an elements-only
approach. But if you want to maintain the view that attributes are only
for metadata, you would use child elements for the data instead.
>
> And to add a specific question.
>
> I want to define a set of 64 bit flags, and I want to only define ones that
> are true.
>
> What do you reckon is the best ways to do this:
>
Some other possibiities than you listed would be
a) <x flags='0 2'/>
b) <x><flags>0 2</flags>... more data ...</x>
In probably most cases beyond the ones you listed, you would have to do
some additional parsing of the flag value.
Without knowing more about what you want to achieve and what tools you
want to use, it is hard to make recommendations about such parsing.
Also, what to do might depend on whether the xml should be easy for a
person to read, or whether you do not care much about that.
> Case 3
>
> <Flags><2></2><7></7><18></18></Flags>
Of coures, you cannot literally have this because element names cannot
begin with a number.
>
> Case 4
>
> <Flags Value="20"> <!- Binary 10100 -->
> <flag3/>
> <flag5/>
> </Flags>
Or you could just use the binary value, since flag3, etc., would be
redundant -
<flags value='10100'/>
<flags>10100</flags>
If human readability of the flag values is not important, this would
probably be the best approach - or you could use the hex values for more
compactness.
> Case 5
>
> <FlagDef>
> <Serif>2</Serif>
> <Italic>7</Italic>
> <SmallCap>18</SmallCap>
> </FlagDef>
>
> <Flags Value="9">
> <Serif>true</Serif>
> <Italic>true</Italic>
> </Flags>
>
Only if human readability were paramount, I would say. If a person only
needed to read the flags once in a while, it might be better to to write
an xslt stylesheet that translates the codes to readable values, and
leave the main format compact (and maybe binary or hex).
> I would like the resulting XML to be easy to parse and to transform ( ie not
> tricky xpath or recursion required).
>
All the above are easy to parse, with or without xpath and xslt, except
for parsing string lists with xslt which is a bit harder - not that
hard, though. Don't fear recursive templates in xslt, either.
It doesn't get hard until the contents of an element have to get handled
differently according to context, or according the the contents or
position of other elements. None of that applies here.
Cheers,
Tom P
|
