Saxon-9.1.0.1 bug with named templates

[ron.vandenbranden]

Hi,

I think I found a bug in Saxon-9.1.0.1that seems to be connected to
named templates. Attached are an XML and XSLT file that make Saxon exit
with following error message:

*** Internal Saxon error: local variable encountered whose binding has
been deleted
Variable name: saxon:current93880728
Line number of reference: 38
Line number of declaration: -1
DECLARATION:
<let variable="saxon:current93880728" as="item()">
  <be>
    <dot/>
  </be>
  <return>
    <literal value="()"/>
  </return>
</let>java.lang.IllegalStateException: *** Internal Saxon error: local
variable encountered whose binding has been deleted
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:521)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:527)
    at
net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.java:489)
    at net.sf.saxon.style.StyleElement.allocateSlots(StyleElement.java:1061)
    at net.sf.saxon.style.XSLTemplate.compile(XSLTemplate.java:364)
    at
net.sf.saxon.style.XSLStylesheet.compileStylesheet(XSLStylesheet.java:1089)
    at
net.sf.saxon.PreparedStylesheet.setStylesheetDocument(PreparedStylesheet.java:346)
    at net.sf.saxon.PreparedStylesheet.prepare(PreparedStylesheet.java:163)
    at
net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:139)
    at net.sf.saxon.Transform.doTransform(Transform.java:682)
    at net.sf.saxon.Transform.main(Transform.java:66)
Fatal error during transformation: java.lang.IllegalStateException: ***
Internal Saxon error: local variable encountered whose binding has been
deleted


The problem does not occur with Saxon8, nor when the named template call
is replaced with the actual instructions of the named template.

Kind regards,

Ron

<?xml version="1.0" encoding="UTF-8"?>
<text>
    <note type="ann">note1</note>
    <note type="ann">note2</note>
</text>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
    <xsl:output method="xml" encoding="UTF-8" indent="yes"/>
   
    <!-- NOTE: no problem when the named template call is replaced with the actual instructions of the named template -->

    <xsl:template match="text">
        <xsl:call-template name="getNotes"/>
    </xsl:template>
   
    <xsl:template name="getNotes">
        <div type="notes">
            <xsl:for-each-group select="//note" group-by="@type">
                <xsl:variable name="counter">
                    <xsl:number count="note[@type= current()/@type]" level="any"/>
                </xsl:variable>
                <div type="{current-grouping-key()}_notes">
                    <p/>
                    <xsl:for-each select="current-group()">
                        <xsl:copy>
                            <xsl:attribute name="id">
                                <xsl:value-of select="concat(@type, '_note', position())"/>
                            </xsl:attribute>
                            <xsl:apply-templates select="@*|node()"/>
                        </xsl:copy>
                    </xsl:for-each>
                </div>
            </xsl:for-each-group>
        </div>        
    </xsl:template>
   
</xsl:stylesheet>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Michael Kay]

I spent some time puzzling why I couldn't reproduce this, then it occurred
to me to modify the stylesheet so that the value of the variable $counter is
actually used, and it now crashes in the way you showed.

I've logged the bug at
https://sourceforge.net/tracker/index.php?func=detail&aid=2014449&group_id=2
9872&atid=397617 and have placed a patch in Subversion.

I'm curious about your expression <xsl:number count="note[@type=
current()/@type]" level="any"/>.

Within a pattern, current() refers to the node that the pattern is trying to
match, which will be the note element. So I think the predicate is always
true.

I haven't explored why the bug goes away if the code isn't in a named
template - I don't think that's significant.

Michael Kay
http://www.saxonica.com/

> -----Original Message-----
> From: saxon-help-bounces@...
> [mailto:saxon-help-bounces@...] On Behalf
> Of Ron Van den Branden
> Sent: 09 July 2008 14:43
> To: saxon-help@...
> Subject: [saxon] Saxon-9.1.0.1 bug with named templates
>
> Hi,
>
> I think I found a bug in Saxon-9.1.0.1that seems to be
> connected to named templates. Attached are an XML and XSLT
> file that make Saxon exit with following error message:
>
> *** Internal Saxon error: local variable encountered whose
> binding has been deleted Variable name: saxon:current93880728
> Line number of reference: 38 Line number of declaration: -1
> DECLARATION:
> <let variable="saxon:current93880728" as="item()">
>   <be>
>     <dot/>
>   </be>
>   <return>
>     <literal value="()"/>
>   </return>
> </let>java.lang.IllegalStateException: *** Internal Saxon
> error: local variable encountered whose binding has been deleted
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:521)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:527)
>     at
> net.sf.saxon.expr.ExpressionTool.allocateSlots(ExpressionTool.
> java:489)
>     at
> net.sf.saxon.style.StyleElement.allocateSlots(StyleElement.java:1061)
>     at net.sf.saxon.style.XSLTemplate.compile(XSLTemplate.java:364)
>     at
> net.sf.saxon.style.XSLStylesheet.compileStylesheet(XSLStyleshe
> et.java:1089)
>     at
> net.sf.saxon.PreparedStylesheet.setStylesheetDocument(Prepared
> Stylesheet.java:346)
>     at
> net.sf.saxon.PreparedStylesheet.prepare(PreparedStylesheet.java:163)
>     at
> net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFa
> ctoryImpl.java:139)
>     at net.sf.saxon.Transform.doTransform(Transform.java:682)
>     at net.sf.saxon.Transform.main(Transform.java:66)
> Fatal error during transformation:
> java.lang.IllegalStateException: *** Internal Saxon error:
> local variable encountered whose binding has been deleted
>
>
> The problem does not occur with Saxon8, nor when the named
> template call is replaced with the actual instructions of the
> named template.
>
> Kind regards,
>
> Ron
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Michael Kay]

 
> I'm curious about your expression <xsl:number
> count="note[@type= current()/@type]" level="any"/>.
>
> Within a pattern, current() refers to the node that the
> pattern is trying to match, which will be the note element.
> So I think the predicate is always true.


I've just been writing some tests for this - there are none in the W3C test
suite!

It turns out Saxon is getting it wrong. It's binding current() to the node
that is the context node at the time the pattern is evaluated, rather than
the node that is being tested against the pattern. It's the same thing in
the common case of xsl:template match patterns, but can be quite different
in other cases. It seems this bug has been present for a very long time, and
might be tricky to fix.

Michael Kay
http://www.saxonica.com/



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[ac-5]

Hi,

I trust you on Java fixing estimates but the XSLT retro-fit will also
require some attention.
Please take your time ... or change the standard ...
or document the release

Thank you.
Cheers,
ac


 

> > I'm curious about your expression <xsl:number
> > count="note[@type= current()/@type]" level="any"/>.
> >
> > Within a pattern, current() refers to the node that the
> > pattern is trying to match, which will be the note element.
> > So I think the predicate is always true.
>  


I've just been writing some tests for this - there are none in the W3C test
suite!

It turns out Saxon is getting it wrong. It's binding current() to the node
that is the context node at the time the pattern is evaluated, rather than
the node that is being tested against the pattern. It's the same thing in
the common case of xsl:template match patterns, but can be quite different
in other cases. It seems this bug has been present for a very long time, and
might be tricky to fix.

Michael Kay
http://www.saxonica.com/



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[ac-5]

HI,

FYI, I have 170 uses of current() in patterns, in over 50 stylesheets
and 20K lines of XSLT, where, along with Saxon, I have assumed that
current() is the "real" context node.  Each of these will require
figuring the context node, assigning it to a new variable and using that
variable in the pattern, and testing and redeploying everything, and
testing these too ....  I understand that I should have doubled checked
with the spec and brought it up sooner ... What about libraries, like
fxsl-xlt2, are they affected too?  Is there an easier way?

inside a pattern, current() = "." seems useless as you can always use
".".  current() should simply  refer either
- to the  immediate preceding node of the current (possibly nested)
pattern, as one walks/traverses nested patterns;  that is the context
node (as curretly with Saxon) if the pattern is not nested and the node
being matched in the enclosing pattern, when the patterns are nested
- to the "real" current context node, outside the pattern (I am not sure
what Saxon does with current() in nested patterns but I have avoided it
because it did not seem orthogonal or was unreliable).

All that time I was dreaming that current() would one day travel the
current parent in nested patterns as that seems like the most probable
and logical node to reference, inside a pattern, apart from the node
currently being matched (already available by default or by ".").  Now
my dream is sad :'(

Leaving current() on the "real" current context node also makes some
sense in that it is possibly the next most probable node reference to be
used inside patterns.

... and even the Java fix could be easier, maybe ...
:-)

Thank you.
Cheers,
ac

> Hi,
>
> I trust you on Java fixing estimates but the XSLT retro-fit will also
> require some attention.
> Please take your time ... or change the standard ...
> or document the release
>
> Thank you.
> Cheers,
> ac
>
>
>  
>
>  
>>> I'm curious about your expression <xsl:number
>>> count="note[@type= current()/@type]" level="any"/>.
>>>
>>> Within a pattern, current() refers to the node that the
>>> pattern is trying to match, which will be the note element.
>>> So I think the predicate is always true.
>>>      
>>  
>>    
>
>
> I've just been writing some tests for this - there are none in the W3C test
> suite!
>
> It turns out Saxon is getting it wrong. It's binding current() to the node
> that is the context node at the time the pattern is evaluated, rather than
> the node that is being tested against the pattern. It's the same thing in
> the common case of xsl:template match patterns, but can be quite different
> in other cases. It seems this bug has been present for a very long time, and
> might be tricky to fix.
>
> Michael Kay
> http://www.saxonica.com/
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help 
>
>  

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Michael Kay]

>
> FYI, I have 170 uses of current() in patterns, in over 50
> stylesheets and 20K lines of XSLT, where, along with Saxon, I
> have assumed that
> current() is the "real" context node.

Thanks for the feedback.

Fixing the problem turned out not to be so difficult after all (though the
code in this area is already messy and has become a little bit messier; it
would be nice to find a cleaner design).

For patterns used in <xsl:template match="XXX"/>, Saxon is already getting
it right.

For patterns used in <xsl:key match="XXX"/>, I believe the match pattern is
currently evaluated with the context node set to whatever it is at the point
where the key() function is first called for that key/document pair. This is
so arbitrary that it's hard to believe any existing code is relying on this.

For patterns used in <xsl:number from="XXX" count="YYY"/>, Saxon is setting
current() (for both patterns) to the node that is the context node when the
instruction is evaluated. Note that this is not necessarily the node that is
being numbered. This is probably the case where an alternative
interpretation from that in the W3C spec might be more intuitive: one could
argue for both "the context node of the instruction" and "the node being
numbered".

For patterns used in <xsl:for-each-group group-starting-with="XXX"
group-ending-with="XXX"/>, I believe Saxon is getting it right: the context
node is the node being matched against the pattern.

So the question is, how many of your 170 uses of current() in patterns occur
in the count and from attributes of xsl:number - and which node are you
assuming it refers to, the node being numbered, or the node that is the
context node?

I don't think there's any case for raising a bug against the spec on this:
the spec is simple and unambiguous, there is no compatibility issue with
1.0, and nothing that the current spec prevents you from doing in some other
way.

I have however raised a bug on another issue that came to light while I was
investigating this: see

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5849

Michael Kay
http://www.saxonica.com/


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[ron.vandenbranden]

Ouch, sorry for what appears to have been a net full of red herring:

Michael Kay wrote:

I spent some time puzzling why I couldn't reproduce this, then it occurred
to me to modify the stylesheet so that the value of the variable $counter is
actually used, and it now crashes in the way you showed.

  -I replaced $counter with position() in debugging my XSLT and forgot to change it back

Michael Kay wrote:

I haven't explored why the bug goes away if the code isn't in a named
template - I don't think that's significant.

  -I tested this again, and now it doesn't seem to make a difference... the error is always there.

Michael Kay wrote:

I'm curious about your expression <xsl:number count="note[@type=
current()/@type]" level="any"/>.

Within a pattern, current() refers to the node that the pattern is trying to
match, which will be the note element. So I think the predicate is always
true.

In following XSLT fragment:

  <xsl:for-each-group select="//note" group-by="@type">
    <xsl:variable name="counter">
      <xsl:number count="note[@type= current()/@type]" level="any"/>
    </xsl:variable>
    ...
  </xsl:for-each-group>
               
I resorted to current() since I gathered current-grouping-key() wasn't allowed in a pattern. I expected current() to refer to the <note> element that is currently matched by <xsl:for-each-group>. Anyway, I found Saxon8's output to be consistent with my expectation:

  <?xml version="1.0" encoding="UTF-8"?>
  <div type="notes">
    <div type="ann_notes">
      <note id="ann_note1" type="ann">note1</note>
    </div>
    <div type="edit_notes">
      <note id="edit_note1" type="edit">note2</note>
    </div>
  </div>

But I'm glad you appear to have found the real problem (despite my misguidance).

Attached are updated XML and XSLT files that do produce above output in Saxon8, but cause the error in Saxon-9.1.0.1.

Kind regards,

Ron

saxontest.xsl
saxontest.xml

[Michael Kay]

> I expected current() to refer to the <note> element that is
> currently matched by <xsl:for-each-group>. Anyway, I found
> Saxon8's output to be consistent with my expectation:

Yes, unfortunately you've written code that relies on Saxon behaviour that
contravenes the spec.

Bind a variable to the relevant node, and then use a variable reference in
the pattern.

Michael Kay
http://www.saxonica.com/


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[ac-5]

Hi Michael,

how many of your 170 uses of current() in patterns occur
in the count and from attributes of xsl:number

none.

In fact, the vast majority of the 170 references to current() were not
patterns but predicates. Sorry for the mix-up.
For the others, Saxon is getting it right.
Fiew ...

Thanks for the info, details, and relief ...

Cheers,
ac


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Dimitre Novatchev]

> What about libraries, like
> fxsl-xlt2, are they affected too?  Is there an easier way?

I don't remember using current() in FXSL.


--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play





On Wed, Jul 9, 2008 at 7:47 PM, ac <ac@...> wrote:

> HI,
>
> FYI, I have 170 uses of current() in patterns, in over 50 stylesheets
> and 20K lines of XSLT, where, along with Saxon, I have assumed that
> current() is the "real" context node.  Each of these will require
> figuring the context node, assigning it to a new variable and using that
> variable in the pattern, and testing and redeploying everything, and
> testing these too ....  I understand that I should have doubled checked
> with the spec and brought it up sooner ... What about libraries, like
> fxsl-xlt2, are they affected too?  Is there an easier way?
>
> inside a pattern, current() = "." seems useless as you can always use
> ".".  current() should simply  refer either
> - to the  immediate preceding node of the current (possibly nested)
> pattern, as one walks/traverses nested patterns;  that is the context
> node (as curretly with Saxon) if the pattern is not nested and the node
> being matched in the enclosing pattern, when the patterns are nested
> - to the "real" current context node, outside the pattern (I am not sure
> what Saxon does with current() in nested patterns but I have avoided it
> because it did not seem orthogonal or was unreliable).
>
> All that time I was dreaming that current() would one day travel the
> current parent in nested patterns as that seems like the most probable
> and logical node to reference, inside a pattern, apart from the node
> currently being matched (already available by default or by ".").  Now
> my dream is sad :'(
>
> Leaving current() on the "real" current context node also makes some
> sense in that it is possibly the next most probable node reference to be
> used inside patterns.
>
> ... and even the Java fix could be easier, maybe ...
> :-)
>
> Thank you.
> Cheers,
> ac
>
>> Hi,
>>
>> I trust you on Java fixing estimates but the XSLT retro-fit will also
>> require some attention.
>> Please take your time ... or change the standard ...
>> or document the release
>>
>> Thank you.
>> Cheers,
>> ac
>>
>>
>>
>>
>>
>>>> I'm curious about your expression <xsl:number
>>>> count="note[@type= current()/@type]" level="any"/>.
>>>>
>>>> Within a pattern, current() refers to the node that the
>>>> pattern is trying to match, which will be the note element.
>>>> So I think the predicate is always true.
>>>>
>>>
>>>
>>
>>
>> I've just been writing some tests for this - there are none in the W3C test
>> suite!
>>
>> It turns out Saxon is getting it wrong. It's binding current() to the node
>> that is the context node at the time the pattern is evaluated, rather than
>> the node that is being tested against the pattern. It's the same thing in
>> the common case of xsl:template match patterns, but can be quite different
>> in other cases. It seems this bug has been present for a very long time, and
>> might be tricky to fix.
>>
>> Michael Kay
>> http://www.saxonica.com/
>>
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> saxon-help@...
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Andre Cusson]

Hi Dimitre,

You are probably right but there might be 1 (curry.xsl, line 174).  The
fxsl Tests also seem to have another 19, says JEdit's Hypersearch.  No
patterns.

As HyperSearch does not allow me to just select the lines and paste them
here, I screen-captured them to the included gif file.

If it does not get to you, but it could still be useful to you (file url
+ line ## + line source), please send me a note so I could either email
it to you directly or put it somewhere on the web for you to pick-up.

Cheers,
ac




Dimitre Novatchev a écrit :
>> What about libraries, like
>> fxsl-xlt2, are they affected too?  Is there an easier way?
>>    
>
> I don't remember using current() in FXSL.
>
>
>  


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help 

[Dimitre Novatchev]

Hi Andre,

> You are probably right but there might be 1 (curry.xsl, line 174).  The fxsl
> Tests also seem to have another 19, says JEdit's Hypersearch.  No patterns.

Thank you for the observations.

I will have a look at these, but so far I haven't noticed any failing tests.

Also, please, note that the file curry.xsl belongs to FXSL 1.x.

FXSL 2.0, which has been available for 4 years uses the file
func-curry.xsl and there is no occurence of current() in this file.

There are 21 occurences of current() and these are only in the test files.


--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play




On Fri, Jul 11, 2008 at 7:52 PM, Andre Cusson
<acusson@...> wrote:

> Hi Dimitre,
>
> You are probably right but there might be 1 (curry.xsl, line 174).  The fxsl
> Tests also seem to have another 19, says JEdit's Hypersearch.  No patterns.
>
> As HyperSearch does not allow me to just select the lines and paste them
> here, I screen-captured them to the included gif file.
>
> If it does not get to you, but it could still be useful to you (file url +
> line ## + line source), please send me a note so I could either email it to
> you directly or put it somewhere on the web for you to pick-up.
>
> Cheers,
> ac
>
>
>
>
> Dimitre Novatchev a écrit :
>>>
>>> What about libraries, like
>>> fxsl-xlt2, are they affected too?  Is there an easier way?
>>>
>>
>> I don't remember using current() in FXSL.
>>
>>
>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@...
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@...
https://lists.sourceforge.net/lists/listinfo/saxon-help