Re: Chameleon components

On 2/18/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
>
> 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'.


I think the element syntax for parameters is nicer for large values.  Since
our
current way of setting parameters is an element, this fits nicely.


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.


Given the above example we have one parameter named
'p:initial-mode' with two values.  I don't see how the component
distinguishes between the two if we collapse the distinction between
a configuration parameter and an application parameter.


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.



Knowing the version of XSLT statically is really important for
interoperability
and for having a conformance story that works for implementors who
aren't going to support XSLT 2.


Besides, I don't think the distinction is too subtle.  It seems to me that
the idea of
having:

  <p:xslt version="1.0"> ...</p:xslt>

or

  <p:xslt version="2.0">...</p:xslt>

is absolutely clear.

The problem arises for custom components where one person's configuration
parameter
is another's application parameter.

The example problem we have to solve is the case of XSLT 1.0 version XSLT
2.0.  We have
three solutions that have been presented:

  1. Separate component names (e.g. p:xslt1 and p:xslt2 ).
  2. An uber-component that takes a version parameter and tries
     to figure out which version is requested based on that parameters
     and the transform's version attribute.
  3. Separating configuration parameters and using element names
      to indicate component types.

As it stands, I think the opinions on these are:

  * While (1) captures the author's intent, it doesn't allow them to
    dynamically choose the XSLT version.  It also sets a precedent
    for an ever expanding set of component types for each version of
    each component's technology.  That means a pipeline author
    has to change pipelines when versions change.

  * For (2), some people did not like the idea of a component having
    a name like "p:xslt" and then having some parameters that help
    it pick implementation versions while others are passed to the
    component's implementation (e.g. stylesheet parameters).  There
    were also issues of name conflicts.  This solution also does
    not really capture author intent all that well.

  *  For (3),  there is a gray area of what is a configuration parameter
     and application parameter.  This distinction and its fuzzy bits
     have made a couple people not like the separation.

     One of the reasons to switch to element names having the
     component's type name is so that a schema element can be
     defined for the configuration parameter.  If we don't have
     configuration parameters, that need goes away.



-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics