W3C home > Mailing lists > Public > xproc-dev@w3.org > December 2008

Re: Calabash problem - primary port(s)

From: James Fuller <james.fuller.2007@gmail.com>
Date: Sun, 7 Dec 2008 17:15:54 +0100
Message-ID: <a0ad8ffe0812070815p3865436fx77662de81da2a990@mail.gmail.com>
To: "James Sulak" <jsulak@gmail.com>
Cc: "Dave Pawson" <dave.pawson@gmail.com>, xproc-dev <xproc-dev@w3.org>

I think the confusion is conflating binding which happens within the
processor to writing to stdout ... also there a few 'default'
conditions within XProc which takes getting used too, but I think
after a few days people will appreciate the 'power user' aspect to
this.

in a simple pipeline the steps are;

a) stdin becomes default source for the top level primary source input

b) steps process, with resulting output naturally binding to the input
of following stpes

c) final result output is default delivered to stdout

commandline switches can control what gets delivered to top level
primary input, as well as define a uri for what happens to the final
result (like serialize to a uri).

In any event, I think the fix for this is putting or repeating (or
putting in a link) of the existing XProc text on this closer to the
initial examples so people don't have to hunt around the entire XProc
spec to understand that there is no p:result-document brother to
p:document.

cheers, Jim Fuller


On Sun, Dec 7, 2008 at 5:06 PM, James Sulak <jsulak@gmail.com> wrote:
> I agree with Dave that his way seems more logical on its face, but I
> think I understand why it was done the way it was (somebody who
> actually knows might want to pitch in).  I suppose it's analogous to
> XSLT, where you can define input and output documents explicitly in
> your transform by using document() and <xsl:result-document />, but
> most of the time, you don't, since not doing it makes your transform
> more portable.
>
> If you look at it that way, leaving the job of binding the output of a
> pipeline to it's caller makes sense.  Although I agree, it would be
> nice to have an easy way to do it within the pipeline.
>
> -James
>
> On Sun, Dec 7, 2008 at 9:32 AM, James Fuller
> <james.fuller.2007@gmail.com> wrote:
>>
>> On Sun, Dec 7, 2008 at 4:23 PM, Dave Pawson <dave.pawson@gmail.com> wrote:
>>>
>>> 2008/12/7 James Fuller <james.fuller.2007@gmail.com>:
>>>> checkout
>>>>
>>>> http://www.w3.org/XML/XProc/docs/langspec.html#ex1
>>>>
>>>> is a good example of p:output getting bound .... the logic especially
>>>> starts making sense in multi branch xproc.
>>>
>>>
>>>
>>>  <p:output port="result">
>>>    <p:pipe step="validated" port="result"/>
>>>  </p:output>
>>>
>>>
>>> That makes sense (to some extent)
>>> For the overall pipleline, take the output from the result port of the
>>> validated step.
>>>
>>> No problem.
>>>
>>> So, If I understand this...
>>>
>>> p:input wrapper
>>>   p:document tells it where to take input from
>>>
>>> p:output wrapper
>>>   p:document tells it where to get output from
>>>
>>> Which written like that seems daft IMHO.
>>>
>>> p:output wrapper
>>>  p:document tells it where to put output
>>>
>>> is a more logical user view IMHO.
>>>
>>>
>>> In summary, for an atomic step
>>> I can't say, within the pipeline, where to
>>> get input from, and where to put output to?
>>> I have to use defaults+the implementation params?
>>
>> thats not the case, u *can* say from within your pipeline, using for
>> example a p:store step
>>
>> or you can resort to defining output binding uri from a commandline switch
>>
>> to be more verbose and explicit you could use p:load step instead of
>> binding document to a port on your pipeline step.
>>
>> ps: I think you are looking for some sugar here ... which I agree
>> would be useful.
>>
>> hth, Jim Fuller
>>
>>>
>>>
>>> Is that roughly right Jim?
>>>
>>>
>>> regards
>>>
>>>
>>> --
>>> Dave Pawson
>>> XSLT XSL-FO FAQ.
>>> Docbook FAQ.
>>> http://www.dpawson.co.uk
>>>
>>>
>>
>>
>
Received on Sunday, 7 December 2008 16:16:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 7 December 2008 16:16:35 GMT