[xsl] XML design for XSLT (was Re: [xsl] Standards checkers for XSLT)

Subject: [xsl] XML design for XSLT (was Re: [xsl] Standards checkers for XSLT)
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 28 Nov 2006 14:56:42 -0500

(The subject line has been changed: this thread started as a discussion of what made for good style in XSLT code; now it's migrated to the design of the XML code itself.)

The reason there's no good rule about elements vs attributes, or how general element types should be, is that this is an area with quite subtle tradeoffs. In that respect one might compare it to a similar debate that has sometimes appeared similarly inconclusive, over whether unnumbered or numbered divs are better (that is, div/div/div vs div1/div2/div3 etc).

Like most XSLT practitioners, I much prefer cleanly recursive models (for reasons most readers of this list will be able to offer); in fact I feel that these days there aren't any really good arguments for hard-coding the nesting level. The only really defensible argument I've heard amounts to "the second way is easier when using X" (programming language, editor etc.) -- and one can meet with surprising resistance when one suggests all the supposed problems of unnumbered (cleanly recursive) divs might be alleviated by reasonably decent and easily acquired tools. Sadly, some are just not in a position to take advantage.

But there, the tradeoffs are much more obvious than they are between




etc.; in this case the choice has far-reaching but subtle effects: on the ease and scaling of certain operations such as selecting, grouping and sorting; on validation against appropriate sets of constraints within the scope of given processing domains (which may be open-ended, or may shift); on reuse of structures within different document contexts; and so forth. But the principle is the same: the tradeoffs are real and in discussing them one soon gets to a point where they seem hard or impossible to reconcile, especially given prejudices, preconceptions, and prior commitments to both particular tools and particular ways of doing things.

Thus, a question like "is it okay to use attributes as key values" doesn't really hold up. The answer has to be "Yeah, sure, why not?" except with the understanding that this is a genuine question, and that sometimes there may be a very good reason why not. It's like asking "Is it okay to put butter cream in the cake frosting?" The answer is "Not only is it okay, it's fairly common". And yet your grandmother might have a serious allergy to dairy products, and you might very much regret having frosted her birthday cake with butter cream.

Thus the real answer, as so often on this list, is "Tell us more". Only this time, it's a hypothetical discussion -- and so, somewhat hard to argue.


At 04:19 PM 11/27/2006, you wrote:
From Doug Rudder Jr.:

My apologies for replying off-list; apparently I need to update my
subscription since our email has been "upgraded" (and names changed),
since my post to the list was kicked back. But here's my two cents worth
on the naming concept:

It depends on the situation. If order and structure are important, using
attributes over elements (yet another permathread) is less than optimal.
I'm dealing with a situation right now where organization is "implied"
by attribute values, and they rely on editorial policy and eyeball QC to
make it work.
It's not working. The error rate (organization/nesting) is very high.
I'm catching the errors by converting all the attribute values to
elements and validating against a more structured schema. In other
words, they cannot adequately parse/QC their own content using
attributes, so I'm helping them clean up their data by providing
feedback from my conversion process. (note: The conversion is for a
specific project, not just for fixing their data problems; that's a side

Frankly, in most (*but not all*) situations I've run across, using
attributes to define content this way scares me. You can't define
"grouping" this way, except in the most general sense, because
attributes cannot enforce element order.


My reply:
I assume that QC means "quality control".

So what you are saying is that this is better:

This also brings up the question when one uses attributes. Is it OK to use attributes for key values?

Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread