Re: Chameleon Component Summary & Proposal

On 2/17/07, Innovimax SARL <innovimax@gmail.com> wrote:
>
>
> Here are the most important objections
> * Configuration parameters could no more be complexType (unless the
> option of allowing configuration parameter to be children is retained)


If the parameter is specified as a child element, they can be a complex
typed.  Right
now, we aren't allow anything but string values.


* How can we define a configuration parameter at runtime ?


You can't.  You use the regular parameters for that.


* It sounds like the language to define user component will look like
> rocket science


Not anymore than right now.  Most simple user defined components
won't need this.


* ignore-prefixes : what will happen if a prefix appear in a here document ?


That doesn't apply.   A here document is passed verbatim and they aren't
in a position where you care about the namespace.  That is, they aren't
in a position where they could be considered a step.


In your examples
> * There is no mention for user defined components of input and output,
> where do they live ?


The same place as now.  The content model is the same as  [p:]step.

Ahead of that
> * p:xslt is too specific compared to p:validate (should be p:transform
> or p:xml-schema)


Well... in the case of XSLT, we do want it to be [p:]xslt because we're
just trying to configure which XSLT version and how the transform
is invoked.

The [p:]validate is very different in that we're choosing between different
validation/schema languages.



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