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

Re: Simple syntax

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 12 Apr 2006 13:53:52 +0100
Message-ID: <443CF860.9060003@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | For the sake of simplicity, perhaps a shorthand for the save component could be
> | to have an optional href attribute on <p:output>, and a save attribute that
> | defaults to true if the href attribute is present.
> What's the save attribute for? 

It's for the case where the URIs for the output documents need to be 
inferred from their base URIs rather than made explicit in the pipeline 
document. In this case, you can't give an href attribute because you 
don't know the href in advance. save="yes" would mean the same as 
omitting the href parameter for the save component.

> What would this mean?
>   <p:output name="document" label="doc1" href="doc.xml" save="no"/>

I was thinking it would be an error.

> Are you thinking of the case where some later component does an
> xinclude of doc.xml but you don't actually ever want to serialize it?

No, I wasn't, but that's an interesting issue.

Personally, I think that "save" should actually mean "register" rather 
than "write" and that it should be implementation-defined whether the 
document actually gets written to the URI. (I.e. use the XSLT 2.0 model 
where the result of a transformation is a sequence of documents 
associated with different base URIs, and it's up to the processor what 
happens with them.)

> If two (or more) steps use the same input, can we assume the pipeline
> engine will be able to infer the tees?

The only problem I can see would be if the pipeline engine wasn't able 
to infer that two or more steps used the same input before the second 
use occurred. That could happen if the engine didn't look at the entire 
pipeline definition ahead of starting the processing or if it couldn't 
be inferred from the pipeline definition that two steps actually used 
the same input. I don't think either of these can occur with the current 
design, but I think we need to steer clear of dynamic inclusion of 
pipeline documents.

> I would like it to be the case that pipeline analysis occurs
> (conceptually) in the following stages:
> 1. Conversion to the XML syntax (if we define a compact syntax)
> 2. Expansion of shorthands (producing a new, valid pipeline with no
>    shortcuts.
> 3. Detection of static errors.
> 4. Evaluation of the pipeline
> But I'm content to visit the question of what shorthands we support,
> and how, until we've got a better handle on the actual language.

Sounds good.


Jeni Tennison
Received on Wednesday, 12 April 2006 12:54:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:39 UTC