Re: Reading ports from XPath functions

Dear all,

I find this use-case very important and that's indeed one area where we
make life probably harder to everyone for no obvious reason.

It also an interesting use case for creating a new compound step in V.next.

Suppose we want to have something like this:

<p:switch-sequence>
   <p:switch-source>
     <p:pipe.../>
  </p:switch>
  <p:branch size="0">
    ...sub pipeline...
 </p:branch>
 <p:branch size="1">
  ... sub pipeline...
 </p:branch>
 <p:otherwise>
   ...sub pipeline...
 </p:otherwise>
</p:switch-sequence>

where size can be xsd:positiveInteger

1 - This would cover this very important use case (for more complex case
where you want range then either we extend it or you go to
p:count/p:identity/p:choose)
2 - This will ask at the same time if XProc is able to add new compound
step in v.next

PS : If you're not happy with the naming, you're welcome to come up with a
better naming, but it should carry that it's about branching on the size of
a sequence
PS2 : It could probably be extended to deal with ranges instead of just
count but that's already a more rare use case
PS3 : if we find new property on sequence that we want to expose we could
use also this structure (do we have other property on sequence ??)

Mohamed


On Sat, Feb 9, 2013 at 4:23 PM, Romain Deltour <rdeltour@gmail.com> wrote:

> Thanks for the thoughts Norm, very clear explanation of the impact on the
> model and implementations.
>
> Limiting it to static step and port names sounds reasonable. Perhaps it
> could be helpful to statically declare the accessed ports somewhere in the
> XPorc model (e.g. in the p:xpath-context); implems wouldn't have to
> statically parse the XPath, and could fail with a dynamic error if the
> declaration of intent is not right.
>
> Anyway, as an example, one use case that comes to mind is a p:choose
> depending on the number of docs appearing on a sequence port:
>
> <?xml version="1.0"?>
> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" name="main"
> version="1.0">
>   <p:input port="source" sequence="true"/>
>   <!-- Count if there are some docs -->
>   <p:count name="count" limit="1">
>     <p:input port="source">
>       <p:pipe step="main" port="source"/>
>     </p:input>
>   </p:count>
>   <p:sink/>
>   <!--Repipe the primary source port-->
>   <p:identity>
>     <p:input port="source">
>       <p:pipe port="source" step="main"/>
>     </p:input>
>   </p:identity>
>   <p:choose>
>     <p:xpath-context>
>       <p:pipe port="result" step="count"/>
>     </p:xpath-context>
>     <p:when test="/c:result = '0'">
>       ...
>     </p:when>
>     <p:otherwise>
>       ...
>     </p:otherwise>
>   </p:choose>
> </p:declare-step>
>
>
> Would be easier done with:
>
> <?xml version="1.0"?>
> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" name="main"
> version="1.0">
>   <p:input port="source" sequence="true"/>
>   <p:choose>
>     <p:when test="empty(p:read-port('some-step', 'result'))">
>       ...
>     </p:when>
>     <p:otherwise>
>       ...
>     </p:otherwise>
>   </p:choose>
> </p:declare-step>
>
> Romain.
>
> On 9 févr. 2013, at 15:20, Norman Walsh <ndw@nwalsh.com> wrote:
>
> > 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
>
>
>