[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
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
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:
[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 |
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[@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.
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@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 |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| RE: [xsl] Recursively looping throu, Brian Martinez | Thread | RE: RE: [xsl] Recursively looping t, cknell |
| RE: [xsl] Recursively looping throu, Austin, Darrel | Date | RE: RE: [xsl] Recursively looping t, cknell |
| Month |