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

Re: copy attributes, except some

Subject: Re: copy attributes, except some
From: ac <ac@xxxxxxxxxxxxx>
Date: Sat, 31 Oct 2009 17:15:13 -0400
Re:  copy attributes
Hi Wendell,

Not all problems can be presented simply. This one had quite a few parameters, including the fact that it was not a single thing but a recurring pattern with growing overhead. It took some time but it works out ok, thanks to everyone who contributed.

Has it is a relatively fundamental XML/XSL pattern I just also submit that it may be worth giving it a second thought in case, at some point in the evolution of XSLT, there is a way to work out a simpler solution. Comparing nodes and comparing node values are quite well taken care of, but comparing node names, in a namespace safe way is a little trickier. It is settled for me now and it may have been useful for others, so maybe it is fine. I may not be a good judge for the relevancy of a more obvious solution, anymore. Maybe better documenting it in the reference manuals could be enough.

In any case, thank you again.

Cheers,
ac




AC,

At 09:02 PM 10/29/2009, you wrote:
Hi Wendell,

True. The thing that still bothers me with this is that since nodes and content are compared, a variable like $excepted-attributes has to be defined for every attribute group, for every tree/subtree that may get copied which is getting to be quite an overhead here.

Yes, certainly. My suggestion is clean only if the variable can be declared at the top -- that is, if @name1 attributes are always to be excluded. Even then, there are situations where it will be problematic.


This is the problem with posting fragments of problems to the list. As we have noted before (in this thread and elsewhere), without a complete problem spec, we can't really provide a solution. For example, a parameterized approach, in which $exclude-attributes would be passed through templates (using a tunnel parameter) and modified where necessary, might be another thing worth trying.

On the other hand, sometimes our waving flashlights in the dark will lead to an accidental insight which is at least as good, or better, than a solution. If that's the case here, we should call it a success.

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

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.