- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Wed, 21 Feb 2007 10:46:13 +0000
- To: public-xml-processing-model-wg@w3.org
Norm, Norman Walsh wrote: > / Jeni Tennison <jeni@jenitennison.com> was heard to say: > | On 2: > | > | I do think we should move to a situation where: > | > | (a) the component name is the element name (i.e. we have <p:xslt2> elements) > | > | (b) parameter names are element names (i.e. we have <p:initial-mode> > | elements inside <p:xslt2>) > | > | My biggest reason for doing this is that it gets us over the problem > | we have distinguishing between application parameters and XSLT > | parameters. If we have: > | > | <p:xslt2> > | ... > | <p:initial-mode>foo</p:initial-mode> > | <p:param name="p:initial-mode">bar</p:param> > | ... > | </p:xslt2> > | > | we can have the initial mode for the transformation as 'foo', and the > | stylesheet parameter $p:initial-mode as 'bar'. > | > | But I do not want to have a situation where some application > | parameters are represented by attributes and some by elements, as this > | will make the language less predictable and therefore harder to author. > | > | Also, it seems that the main distinction between "configuration > | parameters" and "application parameters" is whether they are or need > | to be known statically. That distinction is way too subtle for > | ordinary users, so I suggest that we stick with having just > | application parameters, and leave implementations to do their best. > | Similarly, complex "parameters" can be represented as inputs, and can > | be compiled statically if they're defined as 'here' documents. > > You seem to be saying two different things so let me see if I > understand. You're suggesting that: > > 1. We don't use attributes on the components; the parameters are sub-elements. > 2. The p:param sub-element creates a set of name/value pairs that are passed > to the application > 3. The p:othername sub-elements are used by the processor to setup the > implementation. > 4. We define the set of allowed p:othername sub-elements. > 5. Processors halt if they don't understand the set of p:othername parameters. > 6. I would guess that otherprefix:name sub-elements are implementation-defined. > > Is that right? I think so. To expand a bit more: as I see it, there are three kinds of parameters under discussion: (1) configuration parameters, which have to be set statically, and allow a pipeline engine to select which implementation should be used for a particular step (2) application parameters, which can be set dynamically, and are passed to a component when it's invoked by a pipeline engine, of which there are two sub-categories: (a) pre-defined application parameters, whose names are known in advance (b) arbitrary application parameters, such as stylesheet parameters, whose names are not known in advance As I've said, I don't think we should have configuration parameters, but if we did I think these should be attributes on the step element. Application parameters should be settable using 'select' and 'value' attributes and with the content of an element. I think pre-defined application parameters should be elements whose name is the same as the name of the parameter. Where necessary (such as on the XSLT component), I think arbitrary application parameters, such as stylesheet parameter, should be set using a <p:param> element whose name gives the name of the parameter. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Wednesday, 21 February 2007 10:46:08 UTC