Re: Strange behavior involving (p:)resolve-uri, variables, attributes, calabash, oxygen, saxon, ...

Thanks! That works here as well.

I'll just replace p:resolve-uri with fn:resolve-uri temporarily in the
affected XPath expression while developing (I don't really *need*
compatibility with XPath 1.0 anyway), and switch back when it gets fixed in
oXygen.

Regards
Jostein

2011/12/8 George Cristian Bina <george@oxygenxml.com>

> Hi,
>
> The problem seems to be related to Saxon-EE that oXygen uses with
> Calabash. If I remove the Saxon license from oXygen, for example passing to
> oXygen a license key like the test license key below which does not contain
> the Saxon EE component then I get no errors.
>
> If you try this license key please make sure you also have your oXygen
> license key to restore it.
>
> ------START-LICENSE-KEY------
>
> Registration_Name=oXygen XProc User
>
> Company=
>
> Category=Enterprise
>
> Component=XML-Editor, XSLT-Debugger
>
> Version=13
>
> Number_of_Licenses=1
>
> Date=12-07-2011
>
> Trial=31
>
> SGN=**MCwCFFYYrebvj8G9pQ2NKq9pObUckJ**HqAhR3+qDvOkxRkoGvxbUQLsh5Ht/**
> LGQ\=\=
>
> -------END-LICENSE-KEY-------
>
>
> Best Regards,
> George
> --
> George Cristian Bina
> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> http://www.oxygenxml.com
>
> On 12/8/11 1:52 PM, George Cristian Bina wrote:
>
>> Hi,
>>
>> I was able to reproduce this in oXygen. We will investigate this and I
>> will let you know as soon as we have more information.
>>
>> Best Regards,
>> George
>> --
>> George Cristian Bina
>> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
>> http://www.oxygenxml.com
>>
>> On 12/8/11 12:55 PM, Jostein Austvik Jacobsen wrote:
>>
>>> I've attached the full log from oXygen. This is the essence of it:
>>>
>>> 21996 DEBUG [ Thread-7 ]
>>> ro.sync.xml.transformer.xproc.**calabash.XProcTransformerImpl -
>>> java.lang.**IllegalStateException: *** Internal Saxon error: local
>>> variable encountered whose binding has been deleted
>>> java.lang.**IllegalStateException: *** Internal Saxon error: local
>>> variable encountered whose binding has been deleted
>>> at
>>> net.sf.saxon.expr.**ExpressionTool.allocateSlots(**
>>> ExpressionTool.java:541)
>>> at
>>> net.sf.saxon.expr.**ExpressionTool.allocateSlots(**
>>> ExpressionTool.java:547)
>>> at
>>> net.sf.saxon.expr.**ExpressionTool.allocateSlots(**
>>> ExpressionTool.java:547)
>>> at
>>> net.sf.saxon.expr.**ExpressionTool.allocateSlots(**
>>> ExpressionTool.java:547)
>>> at
>>> net.sf.saxon.expr.**ExpressionTool.allocateSlots(**
>>> ExpressionTool.java:547)
>>> at
>>> net.sf.saxon.expr.**ExpressionTool.allocateSlots(**
>>> ExpressionTool.java:547)
>>> at
>>> net.sf.saxon.expr.**ExpressionTool.allocateSlots(**
>>> ExpressionTool.java:547)
>>> at
>>> net.sf.saxon.expr.**ExpressionTool.allocateSlots(**
>>> ExpressionTool.java:547)
>>> at
>>> net.sf.saxon.sxpath.**XPathEvaluator.**createExpression(**
>>> XPathEvaluator.java:126)
>>>
>>> at
>>> net.sf.saxon.s9api.**XPathCompiler.internalCompile(**
>>> XPathCompiler.java:416)
>>> at net.sf.saxon.s9api.**XPathCompiler.compile(**XPathCompiler.java:397)
>>> at
>>> com.xmlcalabash.runtime.**XAtomicStep.evaluateXPath(**
>>> XAtomicStep.java:754)
>>> at
>>> com.xmlcalabash.runtime.**XAtomicStep.computeValue(**
>>> XAtomicStep.java:643)
>>> at com.xmlcalabash.runtime.**XPipeline.doRun(XPipeline.**java:231)
>>> at com.xmlcalabash.runtime.**XPipeline.run(XPipeline.java:**136)
>>> at
>>> ro.sync.xml.transformer.xproc.**calabash.XProcTransformerImpl.**
>>> transform(Unknown
>>>
>>> Source)
>>> at ro.sync.xml.transformer.xproc.**c$2.run(Unknown Source)
>>> at java.lang.Thread.run(Unknown Source)
>>> 21998 DEBUG [ Thread-7 ] ro.sync.xml.transformer.xproc.**c -
>>> ro.sync.exml.editor.xmleditor.**ErrorListException
>>> ro.sync.exml.editor.xmleditor.**ErrorListException
>>> at
>>> ro.sync.xml.transformer.xproc.**calabash.XProcTransformerImpl.**
>>> transform(Unknown
>>>
>>> Source)
>>> at ro.sync.xml.transformer.xproc.**c$2.run(Unknown Source)
>>> at java.lang.Thread.run(Unknown Source)
>>> 21998 DEBUG [ Transformation Performer ]
>>> ro.sync.exml.editor.xmleditor.**cc<http://ro.sync.exml.editor.xmleditor.cc>
>>> <http://ro.sync.exml.editor.**xmleditor.cc<http://ro.sync.exml.editor.xmleditor.cc>>
>>> -
>>> javax.xml.transform.**TransformerException: Cannot transform
>>> file:/home/jostein/Skrivebord/**debug.xpl because:
>>> javax.xml.transform.**TransformerException: Cannot transform
>>> file:/home/jostein/Skrivebord/**debug.xpl because:
>>> at ro.sync.xml.transformer.xproc.**c.transform(Unknown Source)
>>> at ro.sync.exml.editor.xproc.**transform.m.b(Unknown Source)
>>> at ro.sync.exml.editor.xmleditor.**cc.nd(Unknown Source)
>>> at ro.sync.exml.editor.xmleditor.**cc<http://ro.sync.exml.editor.xmleditor.cc>
>>> <http://ro.sync.exml.editor.**xmleditor.cc<http://ro.sync.exml.editor.xmleditor.cc>>$4.vzi(Unknown
>>> Source)
>>> at ro.sync.ui.application.y.run(**Unknown Source)
>>> Caused by: ro.sync.exml.editor.xmleditor.**ErrorListException
>>> at
>>> ro.sync.xml.transformer.xproc.**calabash.XProcTransformerImpl.**
>>> transform(Unknown
>>>
>>> Source)
>>> at ro.sync.xml.transformer.xproc.**c$2.run(Unknown Source)
>>> at java.lang.Thread.run(Unknown Source)
>>> ---------
>>> ro.sync.exml.editor.xmleditor.**ErrorListException
>>> at
>>> ro.sync.xml.transformer.xproc.**calabash.XProcTransformerImpl.**
>>> transform(Unknown
>>>
>>> Source)
>>> at ro.sync.xml.transformer.xproc.**c$2.run(Unknown Source)
>>> at java.lang.Thread.run(Unknown Source)
>>>
>>>
>>> Regards
>>> Jostein
>>>
>>> 2011/12/8 Norman Walsh <ndw@nwalsh.com <mailto:ndw@nwalsh.com>>
>>>
>>> Jostein Austvik Jacobsen <josteinaj@gmail.com
>>> <mailto:josteinaj@gmail.com>> writes:
>>> > I'm getting the error "Internal Saxon error: local variable
>>> > encountered whose binding has been deleted" in my pipeline, and have
>>> > reduced the problem into this pipeline (which I run using oXygen):
>>>
>>> Can you get a stack trace? I'm not sure how to do that when running
>>> >From oXygen, it would be "-D" on the command line.
>>>
>>> > Is this a bug or am I missing something? If it's a bug, can
>>> anyone reproduce it with Calabash,
>>> > or is it an oXygen bug?
>>>
>>> It appears to be an oXygen bug, but it could be my error. I'm baffled
>>> by the differences that work and don't work. If you think it's my bug,
>>> George, let me know and I'll see what I can do.
>>>
>>> With respect to p:resolve-uri or fn:resolve-uri, you really only need
>>> to use p:resolve-uri if you are trying to maintain compatibility with
>>> other implementations based on XPath 1.0. In any XPath 2.0-based
>>> implementation, fn:resolve-uri should work.
>>>
>>> Be seeing you,
>>> norm
>>>
>>> --
>>> Norman Walsh
>>> Lead Engineer
>>> MarkLogic Corporation
>>> Phone: +1 413 624 6676 <tel:%2B1%20413%20624%206676>
>>> www.marklogic.com <http://www.marklogic.com>
>>>
>>>
>>>
>>