Re: XSLT Component

Dear,

It seems we need to define on the parameter declaration, if this
parameter has to be handled by xproc or passed trough directlty to the
component

It seems a simple attribute could do the job, but it seems definetly
necessary for avoiding potential conflict

The other way (but i'm less enthusiatic) would be to lock a namespace
(xproc-params) for that use

Mohamed

On 2/1/07, Alex Milowski <alex@milowski.org> wrote:
>
>
> On 2/1/07, Norman Walsh <Norman.Walsh@sun.com> wrote:
> > / Alex Milowski <alex@milowski.org> was heard to say:
> > |> | Why wouldn't this just be a regular parameter named 'version' that
> > |> | is used to indicate to the component what version of XSLT it must
> > |> | used. If it doesn't match what it has, it "halts and catches fire".
> > |>
> > |> And if I want to pass a parameter named "version" to my XSLT stylesheet
> > |> at the same time, what do I do?
> > |
> > | OK.  Make the parameter xsl:version or some other QName.
> >
> > Any QName you pick has a collision problem to one extent or another.
>
>
> I think this is a non-issue.  Any component that wants to use the
> context parameters both for configuration and for  internal use will
> have this problem.
>
>
> > | We already have that problem for XSLT 2 if we consider setting the
> > | initial template or mode as a parameter.  Some QNames will have to
> > | be both component and stylesheet parameters.
> >
> > I suppose we could allow additional attributes on p:step. But then I'd
> > really think that it would make sense to have two components. The
> > XSLT2 component could have attributes for specifying the initial
> > template or mode.
>
> How can you have special attributes when the invocation is via a p:step
> element?


-- 
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 Saturday, 3 February 2007 10:27:39 UTC