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

Re: Concrete syntax for simple two-step example

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Fri, 07 Jul 2006 17:13:38 +0100
To: Alex Milowski <alex@milowski.org>
Cc: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Message-ID: <f5birm9s899.fsf@erasmus.inf.ed.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alex Milowski writes:

> Henry S. Thompson wrote:
>> (Note this is essentially use-case 1 [1])
>> <components xmlns="[tbd]">
>>  <component name="xsdValidate">
>>   <input name="primary"/>
>>   <input name="schemaDocs" arity="sequence"/>
>>   <output name="primary"/>
>>  </component>
>>  <component name="xslt1.0">
>>   <input name="primary"/>
>>   <input name="stylesheet"/>
>>   <output name="primary"/>
>>  </component>
>> <components>
>
> Is the idea here that if the names match, then
> they don't need to be declared?

Those are just the background declarations, the pipe itself is lower
down.

Assuming you knew that, the defaults are not (entirely) name based, but
sequence-based:

 1) If the first <step> in a <pipeline> has no <input
    name="primary"...>, it's as if it had 

    <input name="primary" source="$.primary"/>

 2) If any other <step> in a <pipeline> has no <input
    name="primary"...>, it's as if it had

    <input name="primary" source="[preceding step name].primary"/>

 3) If there is no <sink name="primary". . . /> in a <pipeline>, it's
    as if it had

    <sink name="primary" source="[last step name].primary"/>

> In that case you need some kind of sibling relationship
> that you don't have.

I think I do have that sibling relationship.

> That is, what about:
>
> <pipeline xmlns="[tbd]">
>
>  <step name="v1" type="xsdValidate">
>   <input name="schemaDocs" href="my.xsd"/>
>  </step>
>
>  <step name="s1" type="xslt1.0">
>   <input name="stylesheet" href="my.xsl"/>
>  </step>
>
>  <step name="s2" type="xslt1.0">
>   <input name="stylesheet" href="my2.xsl"/>
>  </step>
>
> </pipeline>
>
> Which XSLT step is connected to the output of the
> validate step?  In fact, which step starts the
> pipeline.

v1 starts the pipeline, s1 follows it, s2 follows that.  Linear order
is determining, in the absence of explicit primary <input>s.

> This is why I was advocating a wrapper for sequences
> of steps where defaults apply.  Then the sibling
> relationship means "sequence":

That's just what my default is for <pipeline>.  Why shouldn't it be?
Why do we need one wrapper with the default and one without?  That
would just be confusing.  My proposal: one wrapper (<pipeline>), one
default.

> If you want s2 to operate on its own:
>
>
> <pipeline xmlns="[tbd]">
>
>   <sequence>
>
>  <step name="v1" type="xsdValidate">
>   <input name="schemaDocs" href="my.xsd"/>
>  </step>
>
>  <step name="s1" type="xslt1.0">
>   <input name="stylesheet" href="my.xsl"/>
>  </step>
>
>  </sequence>
>
>  <step name="s2" type="xslt1.0">
>   <input name="stylesheet" href="my2.xsl"/>
>  </step>
>
>
> </pipeline>
>
> Then we have:
>
>    input  ->  v1  -> s1
>       \
>        -> s2

To get that, I would write

<pipeline xmlns="[tbd]">

  <step name="v1" type="xsdValidate">
   <input name="schemaDocs" href="my.xsd"/>
  </step>

  <step name="s1" type="xslt1.0">
   <input name="stylesheet" href="my.xsl"/>
  </step>

  <step name="s2" type="xslt1.0">
   <input name="primary" source="$.primary"/>
   <input name="stylesheet" href="my2.xsl"/>
  </step>

  <sink name="primary" source="s1.primary"/>
</pipeline>

[Not clear from your picture/pipeline what the pipeline output is --
I've assumed it's s1's output, and that s2's output goes nowhere.]

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFErogykjnJixAXWBoRAuG+AJ93G2T36lN7YDFlJF/zQybToVnfRgCfb2jx
7SdJRiN9NwPrgmu4LJjKDHw=
=6hJt
-----END PGP SIGNATURE-----
Received on Friday, 7 July 2006 16:13:55 GMT

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