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

Chameleon components

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sun, 18 Feb 2007 21:00:31 +0000
Message-ID: <45D8BE6F.5090903@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Hi,

Here's me weighing in... It seems to me that there are two separable 
issues being discussed here:

1. Should we have (a) components such as "p:transform" and "p:validate" 
which act as interfaces to multiple applications, with configuration 
parameters that choose between them or (b) separate components for 
separate applications such as "p:xslt", "p:xslt2b", "p:xslt2sa", 
"p:xmlschema", "p:relaxng".

2. Should steps be invoked using (a) a generic <p:step type="q:name"> or 
(b) a specific <q:name> element.

I think we should decide 1 first, because if we do want configuration 
parameters (as required by 1(a)) then I think we need to choose 2(b) to 
give a clear distinction between configuration and application parameters.

So, on 1:

I think it's a mistake to bundle multiple applications into a single 
component (i.e. have "p:transform" and "p:validate" steps) because they 
have completely different interfaces. XSLT 1.0 produces a single result 
document; XSLT 2.0 produces many. RELAX NG can check "plausible 
validity"; XSD takes multiple schema documents; Schematron has a 'phase' 
parameter; and so on.

We will end up with a situation where we have huge numbers of optional 
parameters, parameters that are ignored in certain circumstances, inputs 
that must have only one document if a particular application is 
specified and so on. In other words, lots of constraints that can only 
be expressed through fairly complicated natural language.

We will also end up having components whose definitions will have to 
change as new schema and transformation languages emerge. For example, 
"p:validate" will have to handle XML Schema 2.0 at some point. I think 
this will cause big headaches.

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.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Sunday, 18 February 2007 21:00:24 GMT

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