Re: Chameleon components

Norm,

<moz mode="mumbling" intensity="not-that-much"/>

In the perspective you enlight to me with this answer is that it will
defer the complexity to the component definition language.
Furthermore, the validation per se could be difficult, it would
necessite at least a dynamic schema to validate an xproc instance with
"user component".
And even if, regarding what you say, it should be feasable to solve
the authoring issue, it will be a not that easy task

<moz mode="acceptancy" intensity="low" condition="requirements"/>

Imagining going further with this notation,
for consistency with
<p:validate type="XMLSchema" version="1.1"
I propose
<p:transform type="xslt" version="1.0"
so I can add DSSSL, exslt, stx, Omnimark, Balise or anything i like
without having to author a special user component (unless component
definiton language would be available for V1, which I doubt
seriously), just patching my xproc engine

and <p:query type="xquery" version="1.0" extension="update"
so I can put xpath2, sqlx, etc...

<moz mode="waiting-for-miracle" intensity="medium" />

Mohamed

On 2/7/07, Norman Walsh <Norman.Walsh@sun.com> wrote:
> / Innovimax SARL <innovimax@gmail.com> was heard to say:
> | This is supposed to work for component defined by the WG (in core or elsewhere)
> | But what about component used defined ?
>
> As Alex said, I think we'd need to provide a way for users to declare
> additional "component namespaces".
>
> | 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).
>
> I don't follow. If I declare that http://nwalsh.com/xproc/compenents is
> a component namespace, then I can say:
>
>   <x:myFancyComponent xmlns:x="http://nwalsh.com/xproc/compenents"
>       componentParam="foo">
>     <p:parameter name="someName" value="5"/>
>   </x:myFancyComponent>
>
> The user-defined component will have access to both componentParam and
> someName.
>
> | This is from my point of vue a serious limitation for V.next.
>
> Perhaps I didn't understand your concern.
>
> | 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.
>
> I don't know of one. I don't think any of the standard components have
> this requirement. That might require putting structure inside the
> call, or it could be done by reference:
>
>   <x:otherComponent paramRef="fribble">
>      ...
>   </x:otherComponent>
>
>   <x:myData xml:id="fribble">
>     <doc/>
>   </x:myData>
>
> | Then, it will look like <p:xslt, will have similar look as <p:for-each
> | or <p:choose which is a bit annoying.
>
> Yeah, but I can't decide if that's a bug or a feature.
>
> | 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.
>
> The tool will have to know about the extension components, that's
> true.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh
> XML Standards Architect
> Sun Microsystems, Inc.
>
>


-- 
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 20:49:27 UTC