Re: WG working on xproc requirements/use cases v2

Hi,

In addition to what is proposed on the previous "pain points" thread please see the following suggestions. Sorry for the late send, I intended to send it well before TPAC but it slipped my mind.

Usability
==========

* ability to define XPath functions, if possible import XSLT-defined functions (this was mentioned in the previous thread, but I'd find it particularity useful)

* define a built-in extension function that loads documents from readable ports, or allow a sequences of documents to be available as collections in the XPath dynamic context.
  For instance to switch cases depending on the number of elements in the sequence you currently have to
  - use p:count to get the size of the sequence
  - re-pipe the flowing document
  - p:choose with an XPath context piped to the result of the p:count
 This is very verbose for a simple and common task. Mapping readable ports to collections would allow something like:
  - p:when test="count(collection('my-step#my-port')) gt 0"

* allow the declaration of the media type expected on input/output port (as I think it's being discussed for the support of flowing non-XML documents)

* extend the implicit connections based on the media-type declarations above.
For instance, it's not uncommon in our use of XProc to have several "sets" of documents flowing through a sequence of steps. A.g. a file set XML description and sequences of in-memory XML documents. Primary input / outputs are implicitly connected but we do have to explicitly connect the others. It would be great if there was a rule like "an input port expecting document of type X is automatically connected to the readable port with providing documents of matching type X". Explicit connections are needed only if there are several readable port candidates or if not type info is available.


Base URI manipulation
=====================

One of the greatest strength of XProc is that documents flowing through the pipelines have base URIs regardless of whether they correspond to physical files. It makes it possible to manipulate "virtual" file sets which is needed when doing any kind of format conversion, XML-based publishing, etc.

However the manipulation of base URIs could and should be improved IMHO. For instance it is not currently possible to set a document's base URI. Most of the document-producing steps do not allow to configure the base URI of the result, etc. What I propose:

* a step to set the base URI of a document

<p:declare-step type="p:set-base-uri">
     <p:input port="source"/>
     <p:output port="result"/>
     <p:option name="base-uri" required="true"/>
</p:declare-step>

* add a 'base-uri' option to steps that produce new documents (e.g. p:wrap-sequence, p:wrap, etc).

* add a mechanism to set the base URI of documents created with p:inline. If possible the base URI can be set dynamically (e.g. from a variable), but if it's not possible the 'p:set-base-uri' step declared above is enough.


New steps
=========

These is definitely less critical, but it would be convenient to have a p:if compound step:

* <p:if 
      name? = NCName 
      test? = XPathExpression>
     ( p:xpath-context?,
       subpipeline) 
  </p:if>

Applies the sub pipeline if the test is matched, else the identity. This can be easily achieved with p:choose, but is common enough to deserve its own step. 

* a step to iterate over 2 sequences, like a p:for-each but with 2 iteration sources that are iterated in parallel (1st doc of each, 2nd doc of each, etc). On second thought I think this can covered by p:pack / p:for-each / p:unwrap.


Thanks,
Romain.


--
Romain Deltour, Software Developer
The DAISY Consortium
http://www.daisy.org

On 11 oct. 2012, at 14:26, James Fuller <james.fuller.2007@gmail.com> wrote:

> Hello,
> 
> Just a reminder to everyone that the W3C WG is now formulating v2.0
> requirements and use cases doc and now is the time for you to get your
> thoughts registered about what v2.0 for XProc needs to do for you.
> 
> Please send your thoughts here;
> 
>     public-xml-processing-model-comments@w3.org
> 
> follow along the meeting minutes/agenda here http://www.w3.org/XML/Processing/
> 
> thx for your valuable input.
> 
> Jim Fuller
>

Received on Tuesday, 30 October 2012 10:04:31 UTC