- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Mon, 24 Jul 2006 21:26:18 +0100
- 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 UTC