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

Re: p:pipeline

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 24 Jul 2006 21:26:18 +0100
Message-ID: <44C52CEA.9000900@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Rui,

Rui Lopes wrote:
> Yes, good point. But the main issue on your approach regarding multiple 
> pipelines in one file, IMO, is that it will allow two document roots 
> *with different semantics* for  an xproc document: <p:pipeline> and 
> <p:pipelines>. I'm not against it, neither in favour. But it has the 
> same feeling as stating that an xslt document may begin with 
> <xsl:template> or <xsl:stylesheet>.

Well, XSLT *does* allow either <xsl:stylesheet> or a literal result 
element as a root. <xsl:stylesheet> is for full stylesheets; literal 
result elements are for simple stylesheets -- they're equivalent to a 
single template matching the root node. (Hardly anyone uses the 
literal-result-element-as-stylesheet option.)

But just because XSLT gives users that choice doesn't mean that XProc 
should. I'm very happy if all XProc documents have to have <p:pipelines> 
(or whatever) as their document root. I'm fairly happy if there's a 
choice. I'm just not happy if I have to put each pipeline definition in 
a separate file.

>> I'm somewhat equivocal. There's an advantage in having 
>> <p:declare-component> as part of XProc in that it means *any* XProc 
>> processor (or indeed XML editor) can check that the XProc document 
>> itself is constructed correctly (calls each component with the 
>> correctly named inputs and outputs). It's then an error if an 
>> implementation either doesn't support that component (doesn't have a 
>> definition for it) or has a different signature for the component than 
>> that given in the XProc file.
> 
> So you're saying that it has a more schema-ish flavour, instead of 
> config-ish?

I think that component declarations need to do both things: declare the 
(expected) signature of the component (schema-ish) and define how to 
actually perform the process (config-ish). The former would be easy for 
us to define. The latter is more difficult because different programming 
languages/environments are going to have different requirements, and we 
can't predict them all. So it might be better to leave the config-ish 
parts implementation-defined, and have the schema-ish parts act as a 
place to put the implementation-defined information.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Tuesday, 25 July 2006 16:15:38 GMT

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