Re: Auxiliary documents

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Norman Walsh wrote:
|> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
|> 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.
|
| Presumably you have some implementation in mind that wouldn't be able to act as
| a resource manager?

I believe Richard's implementation plan is to use a series of
independent programs bound together in a shell script generated from
the pipeline document. It's not obvious to me that a resource manager
is practical in that strategy. (Though I can imagine a way to do it
with XML Catalog files and a little cleverness.)

| The reason I'm in favour of mandating that the pipeline engine acts as a
| resource manager is to avoid the possibility of side effects. To avoid side
| effects, we need to ensure that the same document is returned every time it's
| requested (during a single invocation of a pipeline). We also need to make sure
| that we don't get the situation where two components write to the same URI.
|
| I want to avoid side effects so that it's possible to have parallel-processing
| distributed pipeline engines.

Yes, exactly.

[...]
|> case. Perhaps we need to allow pipelines to indicate that one
|> component depends on another even though it doesn't appear to.
|
| Yes, I think we probably do need that facility for the cases where the URIs of
| the outputs of a step aren't made explicit in the pipeline document.
|
| But I think that if the URI of an output document is specified in the pipeline
| document then the user shouldn't have to indicate what order the steps need to
| be run in. In your example:
|
|> <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>
|
| when the XInclude step requests otherdoc.xml, the pipeline engine
| should be able to recognise that otherdoc.xml is a result of the
| XSLT step, and therefore run the XSLT to produce it.

Oooh! I don't know. That strikes at the heart of the "foward chaining"
vs. "backward chaining" question. My current thinking is that the
pipeline processor should be able to look at the pipeline and
determine an order before it begins execution.

A pipeline engine that is capable of noticing in the middle of
processing that it needs something that is, in fact, the result of
some other step is really required to do a lot of dynamic dependency
analysis and I think we're trying to avoid imposing that requirement
on all processors.

In fact, one answer to the question is simply to say that no step can
be executed before all the steps that precede it (and will be
executed) have been executed. Then document order in the pipeline
document determines the implicit dependencies. But that fouls parallel
execution, so I'm not sure I want to go there.

                                        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.