Re: Inputs and outputs

/ 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:

  <p:pipeline>
    <p:declare-output port="foo" ref="endpoint">
    ...
    <p:step kind="something">
      <p:output port="result" name="endpoint"/>
    </p:step>
  </p:pipeline>

or

  <p:pipeline>
    <p:declare-output port="foo" name="output"/>
    ...
    <p:step kind="something">
      <p:output port="result" ref="output"/>
    </p:step>
  </p:pipeline>


| BTW, I think that the 'ref' design only works if you have compound
| names, because it means that inputs and outputs are given an implicit
| label so you only have to worry about forging the connection from one
| end (rather than giving both ends the same label). Otherwise you run
| into problems with <p:declare-output> within <p:choose> or
| <p:for-each> because these elements have to act as both anchors and
| pointers, and you can't do both with a single attribute.

I'm thinking the name attribute gives the anchor and ref gives the
pointer. What am I missing?

|> | 4. For what it's worth, I think non-technical users will balk at
|> | having to include all the extra "pipework", such as declaring all the
|> | inputs for the choice (so that it can standalone) and having a
|> | bitbucket for unused inputs so that it passes static processing. I
|> | don't think it scales very well when you have lots of branches that
|> | use different inputs, or nested choices.
|>
|> Yeah, I don't expect to get my way on that one, but I still think it's
|> nice. I think of it something like a function declaration. You
|> wouldn't refer to global variables from inside your function, would
|> you? :-)
|
| Well, sometimes, but I can tell you that I have absolutely no problems
| referring to function arguments from within an if/then/else (and that
| seems to be the more appropriate analogy)!

*Shrug* I don't think I'm going to win this one so I'm not going to
try very hard :-)

|> 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.

But in this case, I think you're probably right.

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.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.