Re: manifest based processing

On 19 February 2014 14:39, Romain Deltour wrote:

> Again, I've not put enough thinking on the topic to have a
> clear picture.  But one thing to consider is that the person
> who writes the step is not necessarily the person who uses it.
> How would that work with custom modes ?

  I am not sure about details either, but let's assume one can
declare kinds the following way:

    <p:kind name="epub:manifest"
            as="document-node(element(epub:manifest))"/>

    <p:kind name="epub:content" sequence="true"/>

  Those declaration would be part of a library of steps, in the
namespace epub:* itself, defining steps to handle ePUB docs, in
addition to those 2 kinds.

  That is, "epub:manifest" is defined as a kind that validates
the content flowing though, which must be a document with a root
element named "epub:manifest".  The kind "epub:content" is
defined as any sequence of document.  Or maybe we want to unify
those syntax, especially if ports can handle any XDM, and not
only documents:

    <p:kind name="epub:content" as="document-node()*"/>

  The steps of that library, as well as any step written by
anyone, could then declare input and output ports with that kind.
Those declared as primary would then connect implicitly:

    <p:import href="epub.xpl"/>

    <p:declare-step type="my:foobar">
       <p:input port="manifest" primary="true" kind="epub:manifest"/>
       <p:input port="content"  primary="true" kind="epub:content"/>
       ...
    </p:declare-step>

    <!-- 2 primary output ports, of kind manifest and content -->
    <epub:read/>

    <!-- 2 primary input ports, of same kinds, are connected -->
    <my:foobar/>

  Just an idea... (waw, writing XProc on a plain email text
editor is quite a challenge)

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

Received on Wednesday, 19 February 2014 14:57:04 UTC