& XSLT 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@[...].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@[...].com> 
--~--