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

Re: Auxiliary documents

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Wed, 12 Apr 2006 08:20:11 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87fykjouis.fsf@nwalsh.com>
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| My take on this is that we *must* support XInclude, and however we support
| XInclude's access to auxiliary documents, the same method should apply to XSLT.
|
| An XInclude processor needs to somehow get hold of a document given a URI.
| Either the pipeline processor controls the retrieval (acts as an entity
| resolver) or the component does. The current design implies the latter.

I don't think the current design takes a position on this point.

Certainly in the implementation that I envision, the pipeline engine
will act as the entity resolver/URI resolver for the components.

I'd like to make that part of the specification, but I'm not sure it's
something that all implementations can reasonably be expected to
support.

I created an issue for it:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=3113

| We also need to decide whether/how to support the situation where the auxiliary
| document is itself the result of a pipeline, or whether we explicitly exclude
| this. We need to say what happens when a "Saved" document is "Loaded" or
| requested as an auxiliary document, particularly if we want to allow parallel
| processing strategies.

Indeed. I'm not sure what we can say about the parallel execution
case. Perhaps we need to allow pipelines to indicate that one
component depends on another even though it doesn't appear to.

<p:pipeline>
  <p:input name="doc1"/>
  <p:output name="doc2"/>

  <p:xslt>
    <p:input name="document" label="doc1"/>
    <p:input name="stylesheet" href="mystyle.xsl"/>
    <p:output href="otherdoc.xml"/>
  </p:xslt>

  <p:xinclude>
    <p:input href="mydoc.xml"/>
    <p:output name="document" label="doc2"/>
  </p:xinclude>
</p:pipeline>

An agressively optimizing pipeline engine, unaware that mydoc.xml has
an XInclude statement that refers to otherdoc.xml might reasonably
assume that it doesn't need to run the xslt component. Or, if we have
a rule that requires all components to run, that it can run the two
components in parallel.

Perhaps:

<p:pipeline>
  <p:input name="doc1"/>
  <p:output name="doc2"/>

  <p:xslt xml:id="foo">
    <p:input name="document" label="doc1"/>
    <p:input name="stylesheet" href="mystyle.xsl"/>
    <p:output href="otherdoc.xml"/>
  </p:xslt>

  <p:xinclude depends="foo">
    <p:input href="mydoc.xml"/>
    <p:output name="document" label="doc2"/>
  </p:xinclude>
</p:pipeline>

This would be an advanced feature not required in many (most?)
pipelines.


                                        Be seeing you,
                                          norm

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

Received on Wednesday, 12 April 2006 12:20:22 GMT

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