W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > May 2006

Re: Syntax

From: Alessandro Vernet <avernet@orbeon.com>
Date: Wed, 17 May 2006 19:27:08 -0700
Message-ID: <4828ceec0605171927s175d1213i84465d99db2843d2@mail.gmail.com>
To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>

On 5/17/06, Norman Walsh <Norman.Walsh@sun.com> wrote:
> We've been kicking syntax around for a bit. Unfortunately, I don't see
> consensus forming anywhere in particular. I think I still prefer a
> simple, syntactically regular formulation for "ordinary" components:
> <p:step name="QName">
>   <p:param name="QName" .../>
>   <p:input name="QName" href="someURI"/>
>   <p:input name="QName" ref="someLabel"/>
>   <p:output name="QName" label="aLabel"/>
> </p:step>
> I'm sticking with the "user names each output label" for the time
> being. There are a number of shortcuts we could introduce:
> 1. Multiple references to the same label implies a "tee"
> 2. href on a p:output implies a "save"

I agree on everything above.

> 3. Omitting exactly one required p:output on a step and exactly one
>    required p:input on the following step implies that that output
>    is connected to that input. (Alternatively, components could nominate
>    default inputs and outputs and those could be connected together by
>    default.)

Not sure about this though. We went back and forth on the issue of
implicit connections between steps. The counter-argument is that with
implicit connections one can't know if two steps are connected or not
connected without knowing the interface the components used in the
steps. Comparing this to regular programming languages, it is like
saying that if you see:


If step1 returns something and step2 takes something as a parameters,
than this is equivalent to:

    label = step1()

If this is what we are talking about, I tend to dislike this type of
implicit connection.

>   <p:peephole>
>     <p:step/>
>   </p:peephole>

What would be the semantic of the peephole?

Blog (XML, Web apps, Open Source):
Received on Thursday, 18 May 2006 02:27:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:39 UTC