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

Re: Can solve the N-queens - but can't count!

Subject: Re: Can solve the N-queens - but can't count!
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Thu, 17 Jun 1999 10:41:33 +0200
tree to solve expressions
>>I asked for:
>> > - Allow applying match patterns to variables containing result tree
>> > fragments.

Jonathan Borden <jborden@xxxxxxxxxxxx> wrote:

> Would this be a select pattern? e.g.
>
> <xsl:apply-templates select="$var/a[@b='x']" />
> or
> <xsl:value-of select="$var/a" />


Both; that's exactly what I had in mind. It isn't valid at the moment. And
yes, this can be worked around by chaining XSLT stylesheets, if there was a
way to specify them.

Is this legal today? James clark wrote:

>You cannot use a variable as a location step, but the above examples are
>valid.  See production [18] PathExpr.

And yes, PathExpr does allow "$Variable" as the first thing in a path
(section 6.2.1, "PrimaryExpr") However, giving XT the above or even:

<xsl:copy-of select="$var/a"/>

Causes the error:

DID NOT EXPECT cannot convert to node-set

And there's no word in the limitation sections about this. Given James is
also the editor of the draft and the implementer of XT, I find the whole
combination somewhat confusing. Examining the draft, I find that the
introduction to section 6 states:

"Certain contexts in XSLT make use of a pattern. A pattern specifies a set
of conditions on a node. A node that satisfies the conditions matches the
pattern; a node that does not satisfy the conditions does not match the
pattern. The syntax for patterns is a subset of the syntax for expressions.
In particular location paths that meet certain restrictions can be used as
patterns. An expression that is also a pattern always evaluates to an object
of type node-set. A node matches a pattern if the node is a member of the
result of evaluating the pattern as an expression with respect to some
possible context; the possible contexts are those whose context node is the
node being matched or one of its ancestors."

No word about variables, but maybe this isn't the complete list of
restrictions on patterns. We also have  section 6.2.6:

"The only operations that can be performed on a result tree fragment are to
convert it to a string or a boolean. In particular, it is not permitted to
use the /, //, and [] on result tree fragments.

Expressions can only return values of type result tree fragment by
referencing variables of type result tree fragment or calling extension
functions that return a result tree fragment."

However it isn't defined what a "result fragment" is (there's an editorial
note to fix that). I _assumed_ that a variable holding a node set would
qualify, in which case the code above is invalid and XT is correct. This
assumption could be wrong, but if it holds the above patterns are explicitly
invalid.

So, what's the final verdict? Is <xsl:* select="$var/a"> valid for
<xsl:apply-templates>, <xsl:value-of>, <xsl:copy-of>, etc.), or isn't it? If
not, where is it valid to write "$var/a" (which presumably is in the syntax
for a reason)?

Have fun,

    Oren Ben-Kiki


 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.