Reading ports from XPath functions

Hello world,

At XML Prague, both yesterday in the XProcathon and today in Romain
Deltour's excellent presentation[1], the suggestion was made that it
would be nice to be able to read ports from XPath expressions. I
imagine we're talking about something like this:

  <px:some-step name="somename">...</px:some-step>

  <p:xslt>
    ...
    <p:with-param name="someParam" select="p:read-port('some-step', 'result')/x/y"/>
  </p:xslt>

I can certainly see the appeal, but it's worth pointing out that this
complicates the data flow analysis that an XProc processor must
perform.

Today, the processor can look at the port connections and build the
entire flow graph. With an extension function that can read from
ports, it would be necessary to parse all the XPath expressions in
order to find the connections. That's not too burdensome, but it is
certainly some burden.

And, of course, as soon as you can do p:read-port('some-step',
'result'), someone is going to ask for p:read-port($step, $port) and
that's a whole new can of worms to consider.

(I believe we would *have* to impose the restriction that $step and
$port could be resolved statically, but that wouldn't make users
happy.)

If you only want to read from *one* port, I think you can always get
the results you want:

  <p:xslt>
    ...
    <p:with-param name="someParam" select="/x/y">
      <p:pipe step="somename" port="result"/>
    </p:with-param>
  </p:xslt>

But suppose you want to work with the output of two ports:

  <p:xslt>
    ...
    <p:with-param name="booleanParam"
                  select="p:read-port('a','b')/root > p:read-port('c','d')"/>
  </p:xslt>

Then, you've got to work harder:

  <p:variable name="aroot" select="/root">
    <p:pipe step="a" port="b"/>
  </p:variable>

  <p:variable name="croot" select="/root">
    <p:pipe step="c" port="d"/>
  </p:variable>

  <p:xslt>
    ...
    <p:with-param name="booleanParam" select="$aroot > $croot"/>
  </p:xslt>

(Which may involve introducing a new group, but that's a different problem.)

In short: adding p:read-port wouldn't introduce any new functionality,
it would be a convenience. It would have to have some limitations that
users probably wouldn't expect. On the whole, I can't decide if the
(perhaps significant) additional implementation complexity is worth it[2].

[1] http://www.xmlprague.cz/sessions/#xprocebook
[2] "Implementation isn't the user's problem, that's why we pay programmers."

                                        Be seeing you,
                                          norm

P.S. Lots of XProc love at XML Prague. Yay!

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com