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

Re: Chameleon components

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 21 Feb 2007 10:46:13 +0000
Message-ID: <45DC22F5.8090701@jenitennison.com>
To: public-xml-processing-model-wg@w3.org


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.


Jeni Tennison
Received on Wednesday, 21 February 2007 10:46:08 UTC

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