[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: writing good xml

• To: "'xml-dev@l...'" <xml-dev@l...>
• Subject: Re: writing good xml
• From: "Thomas B. Passin" <tpassin@c...>
• Date: Tue, 24 Feb 2004 09:41:47 -0500
• In-reply-to: <B153B9FFD8A5D411A1AE0050DA7C3AD03E6B3E@ICON041>
• References: <B153B9FFD8A5D411A1AE0050DA7C3AD03E6B3E@ICON041>
• User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

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

• References:
  • writing good xml
    • From: Ronald Kent Gibson <Kent.Gibson@i...>

• Prev by Date: Re: Coding Makes You Dumb
• Next by Date: RE: Coding Makes You Dumb
• Previous by thread: Re: [A bit more] Re: writing good xml
• Next by thread: writing good xml
• Index(es):
  • Date
  • Thread