Re: [xsl] Template matching preceding-sibling.
Subject: Re: [xsl] Template matching preceding-sibling.|
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 19 Nov 2007 14:50:23 -0500
At 11:40 PM 11/16/2007, you wrote:
Right. One way of addressing this is to show us exact code with
input and results (pasted please) in minimal form and also tell us
what processor you're running. There are list readers who run
several different processors in order to check exactly this kind of
thing, and can confirm what you're seeing or help to analyze
relevant factors if they can't. Also, we can collectively establish
quite quickly what a processor should be doing in a given specific
case -- that is, the relevant expertise is available to expose
mistaken assumptions and even reasonable but incorrect interpretations.
The funniest thing is, that in my very first post I did include all inputs and
outputs, copy-pasted. But all XSLT-related responses I got so far were
about this "...[... != ...]" expression - I guess that's because members
immediately spot this commonly misunderstood expression and suppose
it is the problem I'm addressing, without reading attentively my whole message
(and Michael Key's response is an obvious cue of this).
In response, first a bit of list philosophy, then another look at the problem:
In line with what you say -- experience would suggest that the best
way of approaching communications on the list (or any email
discussion list for that matter) is to regard each message as being
much like an XSLT template. Each message has a context, yes, but what
it can assume from that context is carefully defined, and does not
include what called it -- the control flow, if you like -- which is
to say, whatever earlier messages might or might not have provoked it.
It's as if "XSLT" as a problem domain were a huge shaggy document
coming to us in a big "push", all our messages were templates trying
to process bits of it, and the output is the same as the input only
transformed from problem statements into solutions.
As you know, XSLT (the technology, not the analogy) is
side-effect-free and "functional" as opposed to procedural. This
means that nothing can be assumed about processing context except
what is given (the context node, variable bindings in scope, etc.).
This is why (stepping over to the analogy) echoing back selected bits
of earlier messages is so useful, even when it is repetitive. It
means that a new process (a.k.a. "reader" or "contributor") can
operate on the problem without having to run the entire thing back
from the beginning. Repeating relevant bits of earlier messages is a
way of parameterizing the thread so that each message to the list can
be properly and cleanly encapsulated.
This makes the entire operation much more robust, as well as better
supporting an arbitrary number of processors (readers) each doing
what it does best, in a kind of "just in time" architecture.
More practically, this suggests both why recapitulating and repeating
relevant bits of information is good etiquette, while recapitualing
and repeating irrelevant bits is bad form. Similarly, cutting down
examples to the minimum is really helpful since it optimizes
processing each message. And posts which follow all the rules of good
form have significantly faster throughput, there being less noise
that has to be ignored (and ignoring noise takes work).
Likewise, saying "see the earlier message in the thread please" is an
architectural violation, however politely requested, inasmuch as it
asks to depend on a side-effect. Do you really want to exclude any
reader who doesn't remember the earlier message or never read it, or
doesn't have the time or patience to go back? That will be a
significant number of us. Of course, we're human beings, so we can
adapt. But one shouldn't expect the same performance out of the
collective brain (the Aggegrated Wetware Processor) when it has to
scramble to adapt as when it is able to run at its best.
Now, as to the question itself: I admit I've tried more than once to
determine what you're asking for, and I'm still somewhat confused. I
think the reason for this is that it's not clear whether the issue
remaining (if there is one! :-) regards the XPath expression, or
whether XPath processors are working properly (getting the same
results for the same input), or other issues, for example regarding
the fit between possible solutions and actual problems.
When I see
match="Rec[activity != preceding-sibling::Rec/activity
I understand the pattern (my brain has an XPath processor in it :-)
to match any 'Rec' element that either has an 'activity' child not
equal to the 'activity' child of a preceding-sibling 'Rec', or has no
preceding sibling 'Rec' to look at.
So given this input:
The first Rec matches the pattern, since it has no preceding sibling
Rec (so it passes the second test).
The Rec also matches the pattern (by passing the first test), as
it has preceding siblings whose 'activity' value is not equal its own
('swimming' is not equal to 'biking' and not equal to 'boating').
Similarly, Rec also matches the pattern, for the same reason
('boating' is not equal to 'biking' or 'swimming').
The only one that does not match is Rec -- it fails the first
test, not having a preceding sibling with a different value. And it
fails the second, since it has a preceding sibling.
Like other readers of the thread, I'm somewhat mystified as to why
would want this behavior. One can easily envision a requirement to
leave Rec out, but not one to leave Rec out but include Rec.
Moreover, although I think you've tried to reassure me :-), I'm not
convinced whether you actually want this behavior, or actually want
the more normal case (include Rec and exclude Rec), except you
just haven't come across a test case which introduces the problem
with it. Or perhaps, like many contributors, you're interested
primarily in the academic question (which is fine).
Which goes back to the usefulness of clarifying the issue by
producing small examples. We've snipped bits of XPath and discussed
their differences in natural language. But we haven't actually looked
(as far as I know :-) at a test case that would dramatize those
differences and show why one would prefer one to the other.
We haven't, however, found any cases where processors behave
differently given the same input, which also seems to have been a concern.
Just in case if somebody is still interested in this issue I'll
quote here this
message, but personally, now I almost 100% sure that it's ok and the input
is transformed correctly with this template.
Date: Wed, 14 Nov 2007 10:00:53 +0600
From: "Ilya Konanykhin" <ilya.konanykhin.ml@xxxxxxxxx>
Subject: Re: [xsl] Template matching preceding-sibling.
I'm asking for clarification of the topic being on the list several
days ago (Nov 8). Steve <subsume@xxxxxxxxx> wrote:
I'm missing something fundamental, what is it?
<xsl:template match="Rec[activity != preceding-sibling::Rec/activity
Above should only print anything once, but I'm getting it each time.
What am I not getting?
Charles Knell and Scott Trenda gave advices/made notices, thus
confirming, that the problem exists. But copying the input data and
the template given by Steve and running it I obtained exactly the
result required by him in the first topic-forming message, if I
understood his request correctly. I used MSXML (not sure about
version, but don't think it's important in this simple case) and
Saxon 9, for the latter I also tried changing template version to
2.0 - the result stood the same. Data follows:
<xsl:template match="Rec[activity != preceding-sibling::Rec/activity
<?xml version="1.0" encoding="UTF-8"?>
As it is clearly seen the string "Ello xslers" appears only once
and not twice as Steve wrote ("hi" comes from the defaul copy
rules, as I understand it).
Did I missed or misunderstood something very basic? Can someone
please reveal the trick to me (especially interested in Charles'
oppinion as he was involved most intensively in the discussion).
Many thanks in advance,
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