Dave,

I know what you mean about the helpfulness of the list and wanting to help
in return... I used to think of myself as a pretty good software engineer
(C, Perl, etc.), but with XSL I can feel pretty incompetent. This list has
kept me alive in the couple of times I've needed a jump-start.

Below is the gist of my problem and solution. Before I get going, I'm using
Michael Kay's InstantSAXON, so I'm using XSLT 1.1. (I know, wrong platform
for the list, but I can't find a good XSL list that suits better than this
one...) So that's why you'll note the conspicuous absense of xxx:node-set()
function calls. And as you'll see, I cheat by using the saxon:evaluate()
function, which I'm not sure I could live without in this case.

And a comment: the algorithm I'm using is nothing like either of the two
original ideas I proposed initially. Perhaps this is a good thing (?), but
I'm still a little bit aggravated at myself that I don't know how to attach
a new attribute to elements in an input document (that is INPUT document;
this is a thinly-masked plea for help if anyone cares to tutor me :-)).

What I'm writing is our next-generation Oracle performance profiler. Instead
of generating HTML directly from our Hotsos Profiler, we're generating XML,
using our own schema definition. This XML is the input document. (It's also
something we hope can be loaded easily into an Oracle database and queried
heavily with SQL.) In a param.xsl file, I have a list of tolerances, that
looks something like this:

    <xsl:variable name="TOLERANCES">
        <p:action name="db file scattered read">
            <p:tolerance rule="@p3&lt;=10" label="blocks &le;
10">0.005</p:tolerance>
            <p:tolerance label="blocks &gt; 10">0.010</p:tolerance>
        </p:action>
        ...
    </xsl:variable>

The idea is that if an Oracle call's average duration exceeds the tolerance
figure, I highlight the call duration in the output. Otherwise, I highlight
something else (the call count). The problems--er,challenges--include:

- The tolerances list will not necessarily contain a p:action element for
every action that might show up in the XML input document. So it's an outer
join.
- The XML document will not necessarily contain an element for every
tolerance in the tolerances list. So it's an outer join from the other
direction as well.
- I want to impose additional grouping on the XML input file elements, as
hinted in the "rule=..." attribute of a p:tolerance element. This was the
real stimulus for my question to the list. In the example shown above, the
p:action element says to group 'db file scattered read' events into two
categories: those with p3<=10, and the of course the remaining events.

Here's a sketch of what I came up with (plz forgive typos; I'm transcribing
and editing heavily, not cuting/pasting):

<xsl:template name="create-oracle-call">
    <xsl:param name="actions"/>
    <xsl:param name="tolerances"/>
    <xsl:param name="rule-number" select="1"/>
    <xsl:choose>
        <xsl:when test="count($actions) = 0">
            <!-- we're finished -->
        </xsl:when>
        <xsl:otherwise>
            <xsl:variable name="pattern">
                $actions
                <xsl:if test="$tolerances/p:tolerance[$rule-number]/@rule">
                    [<xsl:value-of
select="$tolerances/p:tolerance[$rule-number]/@rule"/>]
                </xsl:if>
            </xsl:variable>
            <xsl:variable name="processed-actions"
select="saxon:evaluate($pattern)"/>    <!-- Bless you, M.Kay -->
            <xsl:if test="count($processed-actions) &gt; 0">
                <!-- emit output here -->
            </xsl:if>
            <!-- The following bit was my "breakthrough." It uses tail
recursion to process the remaining (so far
            un-processed) elements, by using a set difference operation to
"subtract" the processed node-set
            from the one that was passed in. -->
            <xsl:call-template name="create-oracle-call">
                <!-- Use set difference operation as shown in Mangano's XSLT
Cookbook, p237 -->
                <xsl:with-param name="actions" select="$actions[count(. |
$processed-actions) != count($processed-actions)]"/>
                <xsl:with-param name="tolerances" select="$tolerances"/>
                <xsl:with-param name="rule-number" select="$rule-number +
1"/>
            </xsl:call-template>
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>

<xsl:template name="create-profile">
    <!-- This thing drives first off the tolerances list and then off all
the elements in the input document that weren't
    processed in the first pass. -->
    <p:profile>
        <xsl:for-each select="$TOLERANCES/p:action">
            <xsl:variable name="this-name" select="@name"/>
            <xsl:call-template name="create-oracle-call">
                <xsl:with-param name="actions"
select="$INPUT//p:action[@name=$this-name]"/>
                <xsl:with-param name="tolerances" select="."/>
            </xsl:call-template>
        </xsl:for-each>
        <xsl:for-each select="$INPUT//p:action">
            <xsl:sort select="@name"/>
            <xsl:variable name="this-name" select="@name"/>
            <!-- The following line is what keeps me from double-processing
elements that have specified tolerances. -->
            <xsl:if
test="not(boolean($TOLERANCES/p:action[@name=$this-name])) and
count(preceding::p:action[@name=$this-name]) = 0">
                <!-- emit output -->
            </xsl:if>
        </xsl:for-each>
    </p:profile>
</xsl:template>

That's it. It seems very XSL-ly because of the recursion and set processing
nature of the solution, and it seems to work like a charm, so I think I'm
satisfied with it. I wonder how anyone would do without saxon:evaluate() (or
something similar) in this type of problem, though...

Thanks again for the hand.


Cary

"David Carnes" <davidc@N...> wrote in message
news:OGRWxwkSEHA.240@T......
> Cary:
> Yeah, I figured your simplified example was extremely, well, simple.
After
> my post I realized that you're the author of "Optimizing Oracle
> Performance."  http://www.oreilly.com/catalog/optoraclep/index.html
> I was wondering why an Oracle guru would want to change the object's state
> just to denote whether it's been read.
> I am very much a neophyte, and have received some wonderful help in these
> newsgroups, whether through replies to my posts, or just lurking and
reading
> other people's questions, and the responses they receive.  So I try to
> answer an easy question or two a week, to give back to the group.  At
first
> glance your question seemed like an easy one.
>
> Since you don't know the what the list looks like at authorship-time, can
> you pass in a parameter to your stylesheet at run-time and just do the
> <xsl:template> bit from my post?  I would be very interested in an outline
> of your solution.
>
> I've been fortunate so far in that I generate both the XML and XSL for my
> apps.  And now that the client I work for has finally upgraded their
Oracle
> from 8.0 to 9i, I am looking forward to sinking my teeth into XML inside
the
> database.  Up until now I've had my packages generate my XML through
> frelling string concatenation.
>
> Thank you for your time,
> Dave
>
>
> "Cary Millsap" <cary.millsap@h...> wrote in message
> news:10bvqcp7p41d153@c......
> > Dave,
> >
> > Thank you. My situation is complicated in such a manner that this
solution
> > won't work as well as I'd like. The list L is supplied from an external
> > source, so I don't have the luxury of authorship-time knowledge of what
L
> > looks like. I have figured out a recursive solution, though, in spite of
> > that. If anyone's interested, respond to this posting, and I can post an
> > outline of how it works.
> >
> > Cary
> >
> >
> > "David Carnes" <davidc@N...> wrote in message
> > news:uR3m3nXSEHA.3988@t......
> > > Cary:
> > > I think <xsl:template> and <xsl:apply-templates> will work for you.
> > >
> > > Given this XML:
> > > <data>
> > >   <thing name="a"/>
> > >   <thing name="d"/>
> > >   <thing name="a"/>
> > > </data>
> > >
> > > ...and this XSL:
> > > <xsl:stylesheet version="1.0"
> > > xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> > >  <xsl:output method='text' indent='yes' omit-xml-declaration='yes' />
> > >   <xsl:template name="data" match="data">
> > >     <xsl:apply-templates select="thing[@name='a']"/>
> > >     <xsl:apply-templates select="thing[@name!='a']"/>
> > >   </xsl:template>
> > >
> > >   <xsl:template match="thing[@name='a']">
> > >     thing 1
> > >   </xsl:template>
> > >
> > >   <xsl:template match="thing[@name!='a']">
> > >     thing 2
> > >   </xsl:template>
> > >   </xsl:stylesheet>
> > >
> > > ...will yield:
> > >
> > >     thing 1
> > >
> > >     thing 1
> > >
> > >     thing 2
> > >
> > > I leave the implementation up to you.  Have fun!
> > > Oh, BTW, download Xselerator; it's a great tool.
> > > http://www.marrowsoft.com/
> > >
> > > Ciao,
> > > Dave
> > >
> > >
> > > "Cary Millsap" <cary.millsap@h...> wrote in message
> > > news:10bs84hh6vspd63@c......
> > > > I have a list L that contains values that are @name attribute values
> in
> > > > elements of the input document. In my application, I need to
traverse
> L,
> > > > processing input document elements whose @name attribute values
match
> > > items
> > > > from L. However, L doesn't contain all the names in the input
> document.
> > > > Therefore, when I'm finished traversing L, I need to walk the input
> > > document
> > > > to process all the elements that weren't processed during the
> traversal
> > of
> > > > L. (There's a simplified example below my signature.)
> > > >
> > > > I can think of two ways to approach this problem, but I'm not sure
> which
> > > is
> > > > a more elegant XSL answer (or even if a way I'm not considering
would
> be
> > a
> > > > smarter way to go):
> > > >
> > > > a) Attach an @has-been-processed attribute to the input document
> > elements
> > > as
> > > > they're processed during the pass through L. (Is it even possible to
> do
> > > this
> > > > in XSL?)
> > > >
> > > > b) Whenever I process a set of elements in the input document,
append
> > > those
> > > > elements' @id values in a separate data structure and then (somehow
> that
> > I
> > > > have yet to figure out) add a predicate that says "...and the
> element's
> > > @id
> > > > value is not in the already-processed list."
> > > >
> > > > Thank you very much for your advice.
> > > >
> > > >
> > > > Cary Millsap
> > > >
> > > >
> > > > Simplified example:
> > > >
> > > > - L contains the names "a" and "b".
> > > > - Input document contains the following elements:
> > > >     <thing name="a" .../>
> > > >     <thing name="d" .../>
> > > >     <thing name="a" .../>
> > > >
> > > > Step 1: For each element in L, process the input document's elements
> > with
> > > > that name. This pass will pick up the two 'a' elements. (I have
> figured
> > > out
> > > > already how to avoid emitting anything for 'b', since it is not
> > > represented
> > > > in the input document.)
> > > > Step 2: For the input document elements that are left over, process
> > those
> > > > elements. This pass will pick up the 'd' element that was not
> addressed
> > in
> > > > Step 1.
> > > >
> > > >
> > >
> > >
> >
> >
>
>