pipe processing problem

[GoogleCodeExporter]

I presume there is a little defect with pipe processing.
Here a sample from wrap-011.xml test. Output port from escape-markup step is 
named "1.1.2/result".
The choose step don't find it for input port and seems to take the default 
pipeline port "1/source" instead.

TRACE step.EscapeMarkupStepProcessor   options = {cdata-section-elements=[], 
method=xml, escape-uri-attributes=false, include-content-type=true, 
indent=false, media-type=text/xml, omit-xml-declaration=true, standalone=omit, 
version=1.0}
TRACE              xproc.Environment writeNodes() port = !1.1.2/result
TRACE           port.EnvironmentPort 1 nodes -> !1.1.2/result
TRACE              xproc.Environment addPorts() ports = 
[output-port(!1.1.2/result)]
TRACE              xproc.Environment setupOutputPorts() step = !1.1.2
TRACE              xproc.Environment setupOutputPorts() step = !1.1.2
TRACE              xproc.Environment addPorts() ports = {}
TRACE              xproc.Environment 
setPrimaryOutputPortAsDefaultReadablePort() step = !1.1.2
TRACE                      step.Step outputPorts = [output-port(!1.1.2/result)]
TRACE              xproc.Environment new default readable port = 
output-port(!1.1.2/result)
TRACE              xproc.Environment addPorts() ports = 
[output-port(!1.1.2/result)]
TRACE              xproc.Environment setDefaultReadablePort() 
defaultReadablePort = output-port(!1.1.2/result)
TRACE                 step.StepUtils writeLogs() step = !1.1.2
TRACE                      step.Step run() step = !1.1.3 ; type = p:choose
TRACE       step.ChooseStepProcessor chooseStep = !1.1.3
TRACE              xproc.Environment newFollowingStepEnvironment() step = !1.1.3
TRACE              xproc.Environment setupStepEnvironment() step = !1.1.3
TRACE              xproc.Environment setupInputPorts() step = !1.1.3
TRACE           port.EnvironmentPort declaredPort = 
input-port(!1.1.3/xpath-context)
TRACE           port.EnvironmentPort portBindings = []
TRACE           port.EnvironmentPort input-port(!1/source) -> 
input-port(!1.1.3/xpath-context)
TRACE              xproc.Environment addPorts() ports = 
{!1.1.3/xpath-context=input-port(!1.1.3/xpath-context)}
TRACE              xproc.Environment setPrimaryInputPortAsDefaultReadablePort() 
step = !1.1.3 ; type = p:choose
TRACE                      step.Step getPrimaryInputPort() inputPorts = 
[input-port(!1.1.3/xpath-context)]
TRACE              xproc.Environment primaryInputPort = null
TRACE              xproc.Environment setXPathContextPort() step = !1.1.3
TRACE                      step.Step XPath context port = 
input-port(!1.1.3/xpath-context)
TRACE                      step.Step parameterPorts = []

Original issue reported on code.google.com by emmanuel...@gmail.com on 12 Mar 2011 at 6:22

[GoogleCodeExporter]

I just added a new test to illustrate the issue. The problem is related to step 
dependency detection. This mechanism is the one used to find out about which 
steps can be run in parallel. And it looks like the "previous step" from the 
p:choose step is not p:escape-markup as it is supposed to be.

More info here: 
http://code.google.com/p/tubular/wiki/ParallelProcessing#Parallel_sub-pipeline_s
teps_execution

I'll fix that.

Original comment by herve.qu...@gmail.com on 13 Mar 2011 at 2:25

• Changed state: Started

[GoogleCodeExporter]

I've committed some fixes. There was also a bug with XPath context port being 
piped to the wrong port.

wrap-011 passes now.

Please tell me if you encounter any further problem related to this issue.

Original comment by herve.qu...@gmail.com on 13 Mar 2011 at 3:41

• Changed state: Fixed