Re: [xsl] Discrepancy in handling current() in a pattern

["G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>]

At 2009-06-10 21:32 +0200, Alain wrote:
> here is what I am trying to do.
> ...
> <!-- First "stack" of matching for vertical lines -->
> <!-- This matches cells that have a vertical lines on their left -->
>
> <xsl:template match="cell[@x != '1' and @z != ../cell[@y =
> current()/@y][@x= current()/@x - 1]/@z]" mode="cell" priority="2">
> ...
> <!-- This matches cells that have a horizontal lines on their top -->
>
> <xsl:template match="cell[@y!='1' and @z != ../cell[@y = current()/@y
> -1][@x= current()/@x]/@z]" mode="cell-2" priority="2">

If you are at the top left cell, then won't both of the above 
template rules match the cell you are at?  That would be ambiguous 
and Saxon is right to report an ambiguous template rule match.

> So my questions:
> ---------------
> 1) Because of the discrepancy I noticed between Firefox and I.E, my
> first question is: "Is current() allowed or not in an XSLT1.0 pattern?"
> (or maybe it is "implementation defined or dependant" but XSLT1.0 is
> unclear about that... or I couldn't find it!)

I see in XSLT 1.0 Section 12.4 the following:

  "It is an error to use the current function in a pattern."

> 2) Is is allowed in XSLT2.0 -should be because Saxon do not complain
> about current() itself, but about its type-, and what is the correct
> expression to remove the recoverable error?

I see in XSLT 2.0 Section 16.6.1 the following:

  "If the current function is used within a pattern, its value
   is the node that is being matched against the pattern."

Therefore the return type is a node (and I trust Michael to have 
implemented Saxon correctly in this regard), so I don't think the 
recoverable error is type related at all.  As I cite above I'm pretty 
sure from your code's documentation (I could not take the time to 
read the detailed code) that the top-left cell is going to satisfy 
the criteria for both template rules.  That would be ambiguous, and 
recoverable.

> /Although I would probably try to code this puzzle differently in 2.0,
> using for example a for-each-group/
>
> 3) Do you think of a better way to program this puzzle that should be
> compatible with both I.E. and Firefox, apart from doing a unique pattern
> with an ugly stack of 2 nested cases/otherwise.

No comment (can't take the time to analyze your logic, sorry).

I hope this helps.

. . . . . . . . . . . . Ken

--
XSLT/XSL-FO/XQuery hands-on training - Los Angeles, USA 2009-06-08
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal