At 2004-03-02 14:29 -0500, Wendell Piez wrote:
At 12:44 PM 3/2/2004, Ken wrote:
At 2004-03-02 08:43 -0800, James A. Robinson wrote:
The feature can contain multiple configs,
each of which I want to merge across features:
...
I want to be able to select /config_datastore/site/* and perform selective
grouping (on feature @name) and merging (on the feature/config elements)
to return:
...
I found I could wrap my head around this problem using variables instead
of keys. An example is below giving your desired results. Note how I
take advantage of the node-set comparison of a single value to a set of
values to get from all configs only those whose feature's name is in a
set of names.
I like this solution. What had occurred to me is to key directly to
parameters, using a compound key value of its configuration id as well as
feature name. But I think Ken's solution is cleaner and more elegant.
It's a case where variable-based grouping such as Ken demonstrates from
time to time on the list has advantages over key-based grouping. Maybe we
think of key-based grouping (or Muenchian document-scoped solutions in
general)
You've hit the nail on the head here, Wendell: key-based functionality
always works with document-wide scope. Whenever I see anything that deals
with any subset of the document, I know I'm going to have to go through
some contortions to work with keys so as to not deal with the entire
document, so I automatically look into variable-based grouping because with
variables I can scope the variable as big or as small as I need.
In this case the subset of the document scope is the set of constructs
whose attribute is in the set of attributes described by another construct:
an idea situation where I can subset the document based on the
applicability criteria and then just group within only what gets addressed
instead of the entire document.
because we've gotten used to that pattern, and haven't quite internalized
the other approach. But I'm making it a point to study the variable-based
solutions when I see them, since this bias (at least on my part) almost
undoubtedly comes from the natural inclination to do what I know works
despite its being more cumbersome and difficult than a less-familiar
alternative, even when that alternative is both cleaner, and arguably
closer to the "spirit" of XSLT.
It isn't a panacea; as I've mentioned before this approach doesn't give you
a predicate with which you can prune a selection for a node list, so there
have been times when I've not been able to use it. I think that is its
only downside, though I grant that key table lookups may be incrementally
faster than variable lookups, though neither actually traverses the source
tree itself so the difference may not be very much at all.
I teach each of axis-based, variable-based and key-based grouping, in that
order, and my students seem to pick up on the pros and cons of each quickly.
................. Ken
--
US XSL training: Washington,DC March 15; San Francisco,CA March 22
World-wide on-site corporate, government & user group XML training
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/s/bc
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list