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

Re: Naming

From: Innovimax SARL <innovimax@gmail.com>
Date: Thu, 10 Aug 2006 23:14:28 +0200
Message-ID: <546c6c1c0608101414y367a23abs8be61bdd6c8460ce@mail.gmail.com>
To: "Jeni Tennison" <jeni@jenitennison.com>
Cc: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Very interesting

I agree that the save will be better if it is the implementation matter, but
anyway, you're just anticipating what will the implementator do for
serializing this kind of functionnality inside the pipesheet so I'm ok.

It's very astonishing how you totally remove the name "port" from your
proposition, but why not !

Please keep going on !

Regards

Mohamed


On 8/8/06, Jeni Tennison <jeni@jenitennison.com> wrote:
>
>
> I have a naming suggestion:
>
> We declare inputs, outputs and parameters with <input>, <output> and
> <param>.
>
> <component name="select">
>    <input name="documents" sequence="yes" />
>    <param name="xpath" required="yes" />
>    <output name="results" sequence="yes" />
> </component>
>
> Diagrammatically:
>
>        |\ /| documents
>    +---+   +---+
>    |  select   |
>    +---+   +---+
>         \ /  results
>
> We invoke components with a <step> containing <pipe> and <param>
> elements. The <pipe> element connects ports together. (We *only* hook up
> inputs; anything we'd want to put on an output we can put on a pipe.)
> Its basic form is:
>
> <step kind="select" name="chapters">
>    <pipe from="validated!result" to="documents" />
>    <param name="xpath" value="//chap" />
> </step>
>
> Diagrammatically:
>
>        |\ /| document
>    +---+   +---+
>    |  validate | validated
>    +---+   +---+
>         \ /  result
>          |
>        |\v/| documents
>    +---+   +---+
>    |  select   | chapters
>    +---+   +---+
>         \ /  results
>
>
> The 'from' attribute points to an output. There can be more than one
> output port named (to provide simple aggregation of documents into a
> sequence). The 'to' attribute points to an input port on the component
> named by the 'kind' attribute on the step.
>
> The <pipe> element can have content for 'here' documents.
>
> It can also provide a place for shorthands for some of the really common
> components. For example (we've talked about the first two; the other two
> are completely speculative):
>
> - @load="URI": loads the document at the URI supplied
> - @select="xpath": filters the documents using the XPath
> - @save="URI": saves the selected documents with the base URI supplied
> - @wrap="QName": wraps the documents into a single document
>
> For example:
>
> <step kind="xslt" name="transform">
>    <pipe to="source" from="validated!result"
>          save="debug/transform/input.xml" />
>    <pipe to="stylesheet" load="style.xsl" />
> </step>
>
> We define the inputs and outputs of pipelines, groups and so on using a
> combination of these elements, by nesting the binding element <pipe>
> within the port definition <input> and <output>. You don't have to use a
> 'to' attribute: the pipe goes to the port that the <pipe> appears in.
>
> In a <group>, ports have two sides: an outside (which provides the
> interface to other steps in the pipeline) and an inside (which provides
> an interface for the steps within the group).
>
>            |
>          |\v/|
>    +-----+   +-----+
>    |      \ /      |
>    |       |       |
>    |     |\v/|     |
>    | +---+   +---+ |
>    | |           | |
>    | +---+   +---+ |
>    |      \ /      |
>    |       |       |
>    |     |\v/|     |
>    | +---+   +---+ |
>    | |           | |
>    | +---+   +---+ |
>    |      \ /      |
>    |       |       |
>    |     |\v/|     |
>    +-----+   +-----+
>           \ /
>
> The pipes go from the outside of the group into the inport port(s) of
> the group, and from the inside of the group into the output port(s) of
> the group. So:
>
> <group name="...">
>    <input name="document">
>      <pipe from="previous-step!result" />
>    </input>
>    <output name="result">
>      <pipe from="inner-step!result" />
>    </output>
>    ...
> </group>
>
> In a pipeline, we only usually deal with the inner sides of the input
> and output ports, so we don't usually have a <pipe> in the <input>.
> However, we can provide defaults, so might have something like:
>
> <pipeline name="ex1">
>    <input name="document" />
>    <input name="calculated" sequence="yes">
>      <pipe from="ex1!document" select="//chap" />
>    </input>
>    <output name="result" sequence="yes">
>      <pipe from="inner-step!result" />
>    </output>
>    ...
> </pipeline>
>
> The other language constructs (<choose>, <for-each> and <viewport>)
> follow the same kind of scheme, though because, in abstract, they take
> pipeline definitions as input, there's some magic involved. I'll try to
> make some suggestions in another mail if there's interest in taking this
> naming scheme forwards.
>
> Cheers,
>
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com
>
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Thursday, 10 August 2006 21:30:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:48 GMT