W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > February 2008

RE: Comments on Editor's Draft 9 January 2008

From: <Toman_Vojtech@emc.com>
Date: Mon, 11 Feb 2008 11:02:43 -0500
Message-ID: <6E216CCE0679B5489A61125D0EFEC78709BD4895@CORPUSMX10A.corp.emc.com>
To: <public-xml-processing-model-comments@w3.org>

> -----Original Message-----
> From: public-xml-processing-model-comments-request@w3.org 
> [mailto:public-xml-processing-model-comments-request@w3.org] 
> On Behalf Of Norman Walsh
> Sent: Monday, February 11, 2008 4:06 PM
> To: public-xml-processing-model-comments@w3.org
> Subject: Re: Comments on Editor's Draft 9 January 2008
> / Toman_Vojtech@emc.com was heard to say:
> | Yes, it is. Thanks for responding to this. I guess I am 
> fine with the 
> | way how it works now, except there is still one thing I am not that 
> | happy with: Because the pipeline must have a "main" (or top-level) 
> | p:pipeline, the specification is effectively forcing the pipeline 
> | author/user to use a certain "interface" (the "source" and "result"
> | ports, plus maybe some additional ports). Internally, you 
> can declare 
> | any sub-pipelines you want, but on the top level, you don't 
> have this 
> | freedom.
> Yes, you do, you just have to use the "full form". There's 
> nothing wrong with a pipeline document that begins:
> <p:declare-step type="my:pipeline" xmlns:p="..." xmlns:my="...">
>   <p:input port="fred"/>
>   <p:input port="barney"/>
>   <p:output port="bedrock"/>
>   <p:xslt ...> ... </p:xslt>
>   <p:xslt ...> ... </p:xslt>
>   <p:xslt ...> ... </p:xslt>
> </p:declare-step>
> and a pipeline processor is expected to be able to run that 
> pipeline just as if it had had "p:pipeline" as its document element.

Except that neither of "fred", "barney" or "bedrock" can be declared
primary and that I always have to make sure that the last step in the
pipeline has a default readable port... But OK, I think I can accept
this cost. I just wanted to point out that it can make some pipelines a
bit cumbersome.

> | While I can see the reasoning behind fixing the "source" 
> and "result"
> | ports, I think it can makes certain things difficult to achieve 
> | (unless wou want to use ugly workarounds in your pipelines). I 
> | understand that the most common use case is: take XML 
> document(s) - do 
> | something - output result XML document(s), but there may be other 
> | (even though possibly weird) scenarios, such as the following:
> Yes, and you can do all those things, just not with the 
> shortcut syntax.

How? Using the described "direct evaluation" of steps?

xproc -i src=x.xml -o res=o.xml \
      -d acme-library.xml -ns acme=http://www.acme.com \
      -pipeline acme:my-pipeline

In order to use the "full form", the pipeline must be declared first
using p:declare-step, so the "direct evaluation" is the only way of
running such a pipeline I can think of.


Vojtech Toman
Principal Software Engineer
EMC Corporation

Aert van Nesstraat 45
3012 CA Rotterdam
The Netherlands

Received on Monday, 11 February 2008 15:59:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:25 UTC