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

Re: Chameleon components

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Tue, 20 Feb 2007 10:58:28 -0500
To: public-xml-processing-model-wg@w3.org
CC: Jeni Tennison <jeni@jenitennison.com>
Message-ID: <87vehwddnf.fsf@nwalsh.com>
/ 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
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,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Tuesday, 20 February 2007 15:59:00 UTC

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