Re: Chameleon components

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| 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.

Exactly. I'm in complete agreement with Jeni.

| 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?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.