Re: Chameleon components

Fellows,

Ok so let me add my 5 cents.

This is supposed to work for component defined by the WG (in core or elsewhere)
But what about component used defined ?

This implies AFAIK that user defined components won't have access to
"component parameters" (as opposed to "instance parameters" to pass
trough to the component).

This is from my point of vue a serious limitation for V.next.

Moreover, is there really no use case for component to have complex
(as opposed to simple, as simpleType) "component parameters" ? In
those case, if they exists, and I supposed they do, the attribute will
be a serious limitation.

Then, it will look like <p:xslt, will have similar look as <p:for-each
or <p:choose which is a bit annoying.

Furthermore, for authoring tool, it won't be so easy to move from a
component call to another, especially from a core one (p:xslt) to a
user defined one (p:step name="my:xslt") and vice versa.

Cheers,

Mohamed

On 2/7/07, Alex Milowski <alex@milowski.org> wrote:
>
>
> On 2/6/07, Norman Walsh <Norman.Walsh@sun.com> wrote:
> > A couple of recent threads have indicated support for a sort of
> > chameleon component that I'd just assumed we wouldn't touch with a ten
> > foot pole.
> >
> > If
> >
> >   <p:step type="validate">...</p:step>
> >
> > can do one of several different kinds of validation (XSD, RNG, SCH)
> > and
> >
> >   <p:step type="xslt">...</p:step>
> >
> > can perform either XSLT 1.0 or XSLT 2.0 transformations, then I
> > think we have a clear need for two different types of parameters
> > (which I'd been hoping, perhaps naively, that we could avoid).
> >
> > If we're going to go this way, I wonder if it's worth revisiting the
> > names of components. Using the types as the GIs would give us two
> > places to put parameters: on the element or in a p:parameter.
> >
> >   <p:validate language="http://www.w3.org/2001/XMLSchema
> ">
> >     ...
> >   </p:validate>
> >
> > and
> >
> >   <p:xslt version="2.0">
> >     <p:param version="1.2"/>
> >     ...
> >   </p:xslt>
> >
> > would be unambiguous.
>
>
>
> Personally, having step types identified by the element name would be much
> better as we could use attributes to configure the step.  That would allow
> differentiation between step configuration (e.g. schema language or
> XSLT version) and parameters to that invocation (e.g. stylesheet
> parameters).
>
> This is certainly inline with many other well known "process control"
> languages (e.g. ant).
>
> In the end, the only issue becomes pipeline validation.  In XML Schema, you
> can
> solve this using a substitution group.  Relax has a similar mechanism.  As a
> pipeline
> "knows" its built-in components, that isn't as much of a problem to
> configure
> the schema.
>
> In XSLT, extension namespaces are identified in some way.  If we did a
> similar thing,
> a pipeline processor would know the difference between a step and some
> random
> markup for documentation or other purposes.
>
> --
> --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


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Wednesday, 7 February 2007 17:48:54 UTC