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

Re: Template matching preceding-sibling.

Subject: Re: Template matching preceding-sibling.
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 19 Nov 2007 14:50:23 -0500
Re:  Template matching preceding-sibling.
Dear Ilya,

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).

Exactly so.


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
           or not(preceding-sibling::Rec)]"

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:

<Rec>
  <activity>swimming</activity>
</Rec>
<Rec>
  <activity>biking</activity>
</Rec>
<Rec>
  <activity>boating</activity>
</Rec>
<Rec>
  <activity>swimming</activity>
</Rec>

The first Rec matches the pattern, since it has no preceding sibling Rec (so it passes the second test).

The Rec[4] 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[3] 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[2] -- 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[4] out, but not one to leave Rec[2] out but include Rec[4].

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[2] and exclude Rec[4]), 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.

Cheers,
Wendell

...
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
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
From: "Ilya Konanykhin" <ilya.konanykhin.ml@xxxxxxxxx>
Subject: Re:  Template matching preceding-sibling.
Message-ID: <00a701c82672$f52f63b0$0200a8c0@KRYGER>

Hi, list!
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
or not(preceding-sibling::Rec)]">
 Ello xslers.
</xsl:template>

<xml>
   <Rec>
     <activity>hi</activity>
   </Rec>
   <Rec>
      <activity>hi</activity>
   </Rec>
</xml>

----

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:


-----------
input.xml:
<?xml version="1.0"?>

<xml>
  <Rec>
    <activity>hi</activity>
  </Rec>
  <Rec>
     <activity>hi</activity>
  </Rec>
</xml>

-----------
input.xsl:
<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:template match="Rec[activity != preceding-sibling::Rec/activity
or not(preceding-sibling::Rec)]">
 Ello xslers.
</xsl:template>

</xsl:stylesheet>

-----------
output.xml:
<?xml version="1.0" encoding="UTF-8"?>

Ello xslers.

hi

-----------

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,
Ilya

Cheers, Ilya


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