[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: default attribute values?

Subject: RE: default attribute values?
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Fri, 02 Aug 2002 17:25:47 -0400
xml defaults
Peter,

At 12:11 PM 8/2/2002, you wrote:
> In fact if you used templates instead of the copy-of, you could generalize
> this for all the attributes:
>
> <input name="default" name2="default2">
>    <xsl:apply-templates select="@*"/>
> </input>
>
> <xsl:template match="node/@*">
>   <xsl:copy-of select="."/>
> </xsl:template>
>
> <xsl:template match="@gunk" priority="1">
>    <xsl:attribute name="name">
>      <xsl:value-of select="."/>
>    </xsl:attribute>
> </xsl:template>
>
> Note that on the template for the attribute whose name is changing (@gunk
> to @name), an explicit priority is necessary to make sure that template
> fires instead of the template that copies.

Wendell, that's a bit obscure (thus, I like it), but it probably makes sense
where you're doing a lot of attribute manipulation. In particular, if you
changed the name of a certain set of attributes on multiple different
elements.  The choose block certainly makes it more obvious what's going on
and I'd guess it's likely is more efficient for the case where you're only
flipping the name on a single attribute for a single element...?

Quite so. Remember the original context was one of copying attribute values, only giving them defaults if they weren't provided, and then the poster asked what if he wanted to change an attribute's name as well.... I was merely extending the logic you had already provided to do the simpler job with xsl:copy-of -- despite the inference one might draw that here the technique had to be abandoned for a choose. :->


As for efficiency, you are quite right, the xsl:choose may be faster ... yet I have learned to hesitate to second-guess what one or another smart compiler might do -- any difference will surely be significant only on very large documents or very dumb processors (or we'd be recommending xsl:choose over match-based template selection all the time, no?).

As for clarity, again you're right, xsl:choose is often clearer especially to the newcomer -- which is all the more reason to expose the "purer" template-driven approach when we can, since it is after all more versatile (and easier to maintain once you understand it), isn't it? In trolling through all the old threads I came across the interesting observation that newbies' code (viz.: lots of xsl:for-each and xsl:choose) often looks horrible to the experienced XSLTer, while our code may just look obscure to the newbie. This is largely due to the slow ramp-up to the powerful template-driven patterns that we eventually get more practice with. All the more reason to expose the alternatives, and discuss the differences, from time to time....

Cheers,
Wendell


====================================================================== 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 ======================================================================


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list



Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.