Hi,
(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
Ford
BMW
Toyota
Maker[.="Ford"]
Maker[.="BMW"]
Maker[.="Toyota"]
Brand[(_at_)type="manufacturer"][sector="automotive"][.="Ford"]
Brand[(_at_)type="manufacturer"][sector="automotive"][.="BMW"]
Brand[(_at_)type="manufacturer"][sector="automotive"][.="Toyota"]
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.
Cheers,
Wendell
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
effect).
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.
Doug
My reply:
I assume that QC means "quality control".
So what you are saying is that this is better:
<Manufacturers>
<Manufacturer>Toyota</Manufacturer>
<Manufacterer>Ford</Manufacturer>
</Manufacturers>
This also brings up the question when one uses attributes. Is it OK
to use attributes for key values?
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--