xsl-list
[Top] [All Lists]

Re: Tricky inclusion match

2005-03-30 13:37:52
Thanks Wendel for the follow up!
I was able to put most of your stuff to work in my "real" scenario but
got a little stuck because my data looks like this (hierarchely)

recordset
  record
    field

where field is "color" and recordset is "picture".
So I am one deeper than the example I gave.  Plus, to confuse things a
little, my field name are field with attribute value name to describe
the element.  So the revised xml would look like (just a snippet of
it):

    <recordset rsName="pictures">
        <record sample="1">
                <field fieldname="color">red</color>
                <field fieldname="color">brown</color>
                <field fieldname="color">red</color>
        </record>
    </recordset>

At any rate, I'm a lot further along then I was!  I had trouble with
preceding-sibling... didn't seem to test correctly.  I all cases, I
always calculated all and did not remove duplicates.

I hope that nobody gets upset because I inquired with a simplified
example of my data, It was easier than trying to describe the real
data I had.

Karl..


On Wed, 30 Mar 2005 13:02:10 -0500, Wendell Piez
<wapiez(_at_)mulberrytech(_dot_)com> wrote:
I was looking at the post I just sent and realized it came out somewhat
incoherently. (It must be an messed-up mail daemon somewhere.)

At 12:27 PM 3/30/2005, I wrote:
Expanded into long syntax the expression looks like this:

child::color[not(self::node() = preceding-sibling::color)][self::node() =
$colors]

That is, it selects all the child 'color' elements, eliminates those whose
values are the same as a preceding-sibling's value, and from those, keeps
those whose values are equal to $colors.

The second predicate (bracketed expression) is a standard idiom for
removing duplicates, and as such is simple enough. For large sets of
siblings it's an expensive test (though it's the analogous test on the
preceding:: axis that really gets expensive), which is why we often prefer
key-retrieval techniques for de-duplication. (In this case the
key-retrieval technique is cumbersome and doesn't gain us much.) You've
seen this: it's central to Muenchian grouping.

This paragraph describes the test in the *first* predicate ... [not(. =
preceding-sibling::*)] ... not the second.

Because of the way the equality operator works with node-sets (it returns
true if the value of any node in the first set is equal to the value of
any node in the second set), this has the result of keeping any color that
is listed among the $colors.

This paragraph describes the test in the second predicate ... [.=$colors]

I hope that helps!

Cheers,
Wendell

======================================================================
Wendell Piez                            
mailto:wapiez(_at_)mulberrytech(_dot_)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(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
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(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



<Prev in Thread] Current Thread [Next in Thread>