Inputs/outputs and auxiliary documents

With respect to the resource manager and auxiliary documents, I
thought Alex made a good case at today's telcon for making these
auxiliary relationships explicit.

Let's consider the case where I generate a stylesheet fragment:

<p:pipeline>
  <p:input name="doc"/>
  <p:output name="output"/>

  <p:step name="p:xslt">
    <p:input name="document" label="$doc"/>
    <p:input name="stylesheet" href="generator.xsl"/>
    <p:output name="output" label="fragment"/>
  </p:step>

  <p:step name="p:xslt">
    <p:input name="document" label="$doc"/>
    <p:input name="stylesheet" href="base.xsl"/>
    <p:output name="output" label="$output"/>
  </p:step>
</p:pipeline>

Suppose that the first step generates frag.xsl which is xsl:input by
base.xsl. We have two problems here: First, a resource manager is
required in order to assure that the output fragment (which we assume
has an appropriate base URI) will be retrieved when the XSLT processor
evalutes <xsl:import href="frag.xsl"/>. Second, there's no explicit
dependency between these two steps, so how can we be assured that
they'll get evaluated in the right order?

Alex proposes, if I understood correctly, that we can solve both of
these problems if we make the auxiliary document relationship
explicit:

<p:pipeline>
  <p:input name="doc"/>
  <p:output name="output"/>

  <p:step name="p:xslt">
    <p:input name="document" label="$doc"/>
    <p:input name="stylesheet" href="generator.xsl"/>
    <p:output name="output" label="fragment"/>
    <p:aux-output href="frag.xsl"/>
  </p:step>

  <p:step name="p:xslt">
    <p:input name="document" label="$doc"/>
    <p:input name="stylesheet" href="base.xsl"/>
    <p:aux-input href="frag.xsl"/>
    <p:output name="output" label="$output"/>
  </p:step>
</p:pipeline>

The additional aux-input/aux-output statements, server to inform
the pipeline that there's an additional dependency here.

Now the processor can determine that the first step has to be executed
first and the resource manager has explicit information about a URI
that it has to manage (freeing it from the burden of managing *every*
URI, if an implementor finds that burden irksome.)

                                        Be seeing you,
                                          norm

P.S. I actually think we should just use p:input/p:output for this
purpose. An p:input or p:output element with no name and an href
attribute would serve the purpose and wouldn't require a new element
name. They are, after all, inputs and outputs.

Note that a declared auxiliary input doesn't have to be output by
another component, but if it is, that other component must be
evaluated first and that document must be captured by the resource
manager. (Or otherwise gauranteed to be retreived later.)

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.