Re: manifest based processing

Interesting idea indeed :)

Note that I didnít mean that using @kind is not a good idea, or worse than @media-type. I simply wanted to clarify what I had in mind in this tweet:

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 ?


On 19 fťvr. 2014, at 14:26, Florent Georges <> wrote:

> On 19 February 2014 14:07, Romain Deltour wrote:
>> b.  what I suggested (on tweeter) was not an extension of the
>> "kind" attribute
>  Interesting.  Actually I missed that part of Jostein's email, I have
> just seen it now that I saw this mention in your own email.  What is
> interesting is that I was writing a response to Jostein suggesting
> exactly the same thing as he did: being able to define the "kind" of a
> port, and being able to connect implicitly outputs ports to the inputs
> ports of the same kind on the net step.
>  In addition to that "use a kind in order to create it", which looks
> like @mode in XSLT 1.0 and 2.0 (a mode exists as soon as you create a
> template rule with a @mode with that name), there could even be a
> p:kind declaration (like XSLT 3.0 introduces xsl:mode).
>  This has 2 advantages: detecting typos (if you make a typo, a new
> kind is not created but the compilation gives you an error), and
> allowing to set properties on the kind itself (is there an opportunity
> to set a content-type?, validate outputs and inputs based on a
> schema?, asking the processor to log all documents flowing through
> ports of a given kind, etc.)
>  That would probably solve verbose explicit bindings between steps of
> the same library or application, acting on the same (sets of) kinds of
> documents.
>  Regards,
> -- 
> Florent Georges

Received on Wednesday, 19 February 2014 13:39:57 UTC