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

Re: Feature Request - Node Set Processing (long)

Subject: Re: Feature Request - Node Set Processing (long)
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 15 Jan 1999 23:57:25 -0500
next arrow gif
At 99/01/13 18:14 +0700, James Clark wrote:
>"G. Ken Holman" wrote:
>> I've come to need a new feature in XSL and though I'm willing to concede it
>> may appear complex, I would find such a feature incredibly useful, and I
>> hope the committee would consider its inclusion in a future WD.
>> 
>> In my XSL work, I have found it useful to consider sets of nodes created by
>> a select statement, and operations on that set using as a focus, the
>> current node in the source tree.
>
>It would seem more natural to me to provide this sort of functionality
>by extending the pattern language to include more set operations and
>more operations on siblings (as in XQL).  Could this be used to solve
>the problems you are trying to solve with your suggested feature?

No, I don't think so ... for two reasons.

First, by operations on siblings I'll assume that your experimental
"next-element()" is an example of such an extension.  Using that function,
the syntax:

   next-element( this |
                 that |
                 theother )

will return the next node iff the next node to the given node in the source
tree context is one of the mentioned nodes, otherwise it returns the empty
node set.

What I need below:

   <xsl:choose select="/course/intro|
                       /course/lesson|
                       /course/exit"
               test="next">
     <xsl:when>
       <a href="{@id}.htm"><img src="active-right-arrow.gif"/></a>
     </xsl:when>
     <xsl:otherwise>
       <img src="inactive-right-arrow.gif"/>
     </xsl:otherwise>
   </xsl:choose>

.... is to look at the set of nodes created by the select expression as a
*complete* set of nodes (throwing away any nodes in between that don't
match the given pattern), and then checking if the node I'm at is in the
set, and if so, see if there is a next node in the set (regardless of where
the next node is in the source tree), and if there is a node then set the
context to that next node for the processing of the actions in the
<xsl:choose>.

The order of members in the set is still in the parse order of the tree ...
but the context of testing proximity is within the set, not within the tree.

The next, previous and this operations are applied to the relationships
found in the set of nodes created by selecting the specified nodes, not to
the relationships found in the source tree of the nodes matching the pattern.

In the example above, there may be /course/* elements in between
/course/intro and /course/lesson, but I want to skip over those and apply
my relationships to the subset of nodes identified by my select request.

The non-iterative set tests I need for my training materials are:

"prev" - <xsl:when> with the node immediately before the current node (both
in the set, based on the relationship in the set, not in the source tree)
       - <xsl:otherwise> if neither node is in the set

"next" - <xsl:when> with the node immediately after the current node (both
in the set, based on the relationship in the set, not in the source tree)
       - <xsl:otherwise> if neither node is in the set

"this" - <xsl:when> with the current node if the current node is in the set
       - <xsl:otherwise> if the node is not in the set

Second, one of the operations is iterative, requiring the engine to walk
through the members of the set and executing either <xsl:when> or
<xsl:otherwise> for each member of the set:


   <xsl:choose select="/course/intro|
                       /course/lesson|
                       /course/exit"
               test="this"
               iterate="yes">
     <xsl:when>
       <img src="green-button.gif" alt="{title}"/>
     </xsl:when>
     <xsl:otherwise>
       <a href="{@id}.htm">
          <img src="blue-button.gif"
               alt="{id(@id)/title}"/></a>
     </xsl:otherwise>
   </xsl:choose>

In the above example, I end up with a button bar the size of my set of
elements, with zero or one of the buttons green and all the others blue.
Again by the "this" type, I'm checking my node current at the start of
<xsl:choose> against each of the members of the set, looking for identity
... only this time it is iterative instead of one-shot.

So, to answer your question, an extended pattern language won't help
because I understand the patterns are used to select nodes from the source
tree, but doesn't change the interpretation of proximity to the selected
nodes, rather, proximity is still determined by the source tree.

Does this explanation make more sense than my first explanation?

Thanks for taking the time to even consider this ... like I said before, it
is all working perfectly right now, only it is in a post process.  Since my
post process is working on the result tree, I suppose I could do this in a
result tree filter, but I (and other non-Java-programmers) would need to
know how to program to work the filter, while my syntax above is wholly
done declaratively.  Also, I could consume a lot of resources iteratively
creating all the possible outcomes and then filtering out only the one
outcome I want.

The action <xsl:for-each> currently works iteratively over the source tree
based on pattern matching ... are the basic building blocks already there
in an engine to work iteratively over a one-dimensional set of nodes
extracted from the source tree into a new context of relative proximity?  

>From a DSSSL perspective, there were many kinds of problems easily solved
by selectively creating a node list and then testing membership in or
iterating over that node list as a new proximity context having lost the
relationships between the nodes in the source tree (yet having finished
working with the set finding the node I want, acting on that resulting
member of the list is in the context of the source tree) ... I see this
syntax as achieving the same: create a node list, act on the results of the
node list; and I don't see how I could have solved my problem with the
existing suite of functions.

Thanks for your patience with this.

.......... Ken


--
G. Ken Holman         mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.  http://www.CraneSoftwrights.com/s/
Box 266,                                V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0            F: +1(613)489-0995
Training:   http://www.CraneSoftwrights.com/s/schedule.htm
Resources: http://www.CraneSoftwrights.com/s/resources.htm
Shareware: http://www.CraneSoftwrights.com/s/shareware.htm
Next XSL Training (see training link):   WWW8 - 1999-05-11


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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.