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

Re: Inputs and outputs

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 24 Jul 2006 12:01:49 +0100
Message-ID: <44C4A89D.8080404@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Norm,

Norm Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | My comment was only about the 'ref' design (which is the one I like
> | most at the moment), and I was trying to make the point that if we
> | adopt *that* design then we *have* to make explicit which way the
> | connection is made with the outputs in <p:choose>, and that for
> | consistency we should also do so with <p:pipeline> and <p:for-each>.
> 
> I think consistency is good. I'm in favor of it, on principle, but I
> don't quite see why it's required by the ref design:

I think we might be talking at cross purposes. Perhaps the point behind 
the 'ref' design is that as long as two elements are linked through a 
name/ref pair, it doesn't matter which has the name and which has the 
ref. I'm just worried that if we allow all combinations then it will be 
confusing for users to read pipelines written in different styles:

OPT 1: outputs point to port declarations

<p:pipeline name="pipe">
   ...
   <p:declare-output port="result" name="pipe.result" />
   ...
   <p:choose name="choice">
     ...
     <p:declare-output port="result" ref="pipe.result"
                                     name="choice.result" />
     ,..
     <p:step kind="..." name="step">
       ...
       <p:output port="result" ref="choice.result" />
     </p:step>
     ...
   </p:choose>
</p:pipeline>

OPT 2: port declarations point to outputs

<p:pipeline name="pipe">
   ...
   <p:declare-output port="result" ref="choice.result" />
   ...
   <p:choose name="choice">
     ...
     <p:declare-output port="result" name="choice.result"
                                     ref="step.result" />
     ,..
     <p:step kind="..." name="step">
       ...
       <p:output port="result" name="step.result" />
     </p:step>
     ...
   </p:choose>
</p:pipeline>

OPT 3: some outpus point to port declarations, some port declarations 
point to outputs

<p:pipeline name="pipe">
   ...
   <p:declare-output port="result" ref="choice.result" />
   ...
   <p:choose name="choice">
     ...
     <p:declare-output port="result" name="choice.result" />
     ,..
     <p:step kind="..." name="step">
       ...
       <p:output port="result" ref="choice.result" />
     </p:step>
     ...
   </p:choose>
</p:pipeline>

> |> But with a little analysis, I can probably manufacture the
> |> declarations myself. (From the point of view of my particular
> |> implementation, I expect to get considerable benefit from the
> |> self-contained nature of choose.)
> |
> | My rule of thumb is that if an implementation can work something out
> | for itself, then the user shouldn't _have_ to make it explicit.
> 
> Well sure, as a rule of thumb. On the other hand, I've seen lots of
> code that compilers had no trouble understanding but which was
> essentially indecipherable to me.

That's why I emphasised _have_: of course it's good practice to write 
stuff that's understandable by others, but that shouldn't mean that 
users should _have_ to write stuff that isn't necessary for 
deciperhability in any particular pipeline.

> By the way, having removed the declarations from choose, we've lost
> the connection between the tests and the stream over which they are to
> be applied.
> 
> I'm going to guess that we'll get pressure to do two things: first,
> make it easy to apply all the tests to the same input document and
> second, make it possible to run tests on different documents.
> 
> The first thing that occurs to me is:
> 
>   <p:choose ref="validxml">
>     <p:declare-output port="result" name="xformed"/>
> 
>     <p:when test="/book">
>       <p:step kind="xslt">
>         <p:input port="document" ref="validxml"/>
>         <p:input port="stylesheet" ref="style"/>
>         <p:output port="result" ref="xformed"/>
>       </p:step>
>     </p:when>
> 
>     <p:when test="/html" ref="validxml">
>       <p:step kind="xslt">
>         <p:input port="document" ref="validxml"/>
>         <p:input port="stylesheet" href="html.xsl"/>
>         <p:output port="result" ref="xformed"/>
>       </p:step>
>     </p:when>
>   </p:choose>
> 
> That is, @ref on choose points to the default stream for tests. But
> each when can have an @ref of its own to override that. Of course,
> both of these refs must point to inputs.

Mmm. That'd work. (Though I still prefer a design where inputs are 
exposed as variable bindings within XPath expressions...)

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Monday, 24 July 2006 12:58:46 GMT

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