XML design for XSLT (was Re: Standards checkers
(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[@type="manufacturer"][sector="automotive"][.="Ford"] Brand[@type="manufacturer"][sector="automotive"][.="BMW"] Brand[@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.
At 04:19 PM 11/27/2006, you wrote:
From Doug Rudder Jr.:
====================================================================== 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 ======================================================================
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format