Re: calling for xproc pain points, requested features, etc

OJ <olivier.jeulin@gmail.com> writes:
> +1 also more steps to work with files: it's annoying to use a "XML pipeline language" if you
> have to call it inside a script that has to
> work with XML files to zip/unzip, copy, rename, delete, select which ones to process (based on
> their metadata (date, …), a shell pattern, ...).
> For each of these steps, we need good error reporting (nonblocking and understandable).

What additional steps would you like? Additional steps are easy and
(usually) don't require any changes to the specification.

> I also think it should be easier to use for someone that is already familiar with XSLT.
>
> For examples:
> 1)
> XProc: p:for-each uses p:iteration-source
>
> <p:for-each name="chapters">
>   <p:iteration-source select="//chapter"/>
>   (do something)
> </p:for-each>
>
> XSLT: xsl:for-each uses select=""
>
> <xsl:for-each select="//chapter">
>    (do something)
> </xsl:for-each>
>
> It would be nice to write instead:
>
> <p:for-each select="//chapter" name="chapters">
>   (do something)
> </p:for-each>
> Less typing, more use of existing knowledge.

Fair enough. The point of p:iteration-source however, isn't the select
attribute. It's for the binding:

<p:for-each name="chapters">
  <p:iteration-source select="//chapter">
    <p:pipe step="someStep" port="somePort"/>
  </p:iteration-source>
  (do something)
</p:for-each>

If the select attribute was all that was needed, we would have put it
on the p:for-each. Having the selection on p:for-each when there *is* a
binding, seems...odd.

> 2)
> With xsl:result-document, @href can be "{upper-case($output-file)}", but this is invalid in
> XProc (!).
> If you want to use a variable with p:store, you can't use href="{$a}", you have to use
> <p:with-option name="href" select="$output-file"/>
> But "{upper-case($output-file)}" is still invalid (!?).

This is valid:

  <p:with-option name="href" select="upper-case($output-file)"/>

Just like XSLT, you don't use curly braces (AVTs) in select attributes.

And having AVTs in V.next is a no-brainer.

> To sum up: could XProc be a bit more developer and XSLT friendly? ;)

Absolutely. Keep those suggestions coming.

                                        Be seeing you,
                                          norm

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