W3C home > Mailing lists > Public > xproc-dev@w3.org > December 2011

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

From: George Cristian Bina <george@oxygenxml.com>
Date: Thu, 08 Dec 2011 21:52:35 +0200
Message-ID: <4EE11583.3000604@oxygenxml.com>
To: Jostein Austvik Jacobsen <josteinaj@gmail.com>
CC: Norman Walsh <ndw@nwalsh.com>, XProc Dev <xproc-dev@w3.org>
I am not sure if there is something that we can fix as the problem may 
be in Saxon. I will try to see if I can force Calabash to use Saxon EE 
outside oXygen to try to reproduce this issue.

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 12/8/11 9:36 PM, Jostein Austvik Jacobsen wrote:
> 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
> <mailto: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> <mailto:ndw@nwalsh.com
>             <mailto:ndw@nwalsh.com>>>
>
>             Jostein Austvik Jacobsen <josteinaj@gmail.com
>             <mailto:josteinaj@gmail.com>
>             <mailto: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>
>             <tel:%2B1%20413%20624%206676>
>             www.marklogic.com <http://www.marklogic.com>
>             <http://www.marklogic.com>
>
>
>
>
Received on Thursday, 8 December 2011 19:53:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 8 December 2011 19:53:00 GMT