Re: In-scope namespaces and parameter values

Norm,

Norman Walsh wrote:
> On the last call, Alex asked about making sure that the in-scope
> namespaces were kept with each p:parameter so that it would be
> possible for steps to interpret QNames in values correctly.
> 
> I can't think of a good way to make this work.
> 
> In particular, I don't know of any APIs that allow you to do this.
> 
> Consider
> 
>   <p:xslt>
>     <p:parameter name="foo" value="x:foo" xmlns:x="XXX"/>
>     <p:parameter name="bar" value="x:bar" xmlns:y="YYY-NOT-XXX"/>
>   </p:xslt>
> 
> Does anyone know of an XSLT engine which accepts a set of parameters
> with different in-scope namespaces for each parameter?

I think we have a problem here, but I don't think this is it. The XSLT 
(2.0) *component* needs to know the in-scope namespaces so that it can 
interpret *options* such as initial-mode/initial-template QNames 
correctly and pass both namespace URI and local name to the XSLT 
processor. But the XSLT (2.0) *processor* itself doesn't get passed 
in-scope namespaces: the values of *parameters* are just strings.

We can say that when a component is invoked it is provided with, for 
each option, a name, a (string) value, and a set of in-scope namespaces. 
The component will know which of the options need to be interpreted as 
QNames, for passing to the processor, and which don't.

For example, if you have:

   <p:xslt2 xmlns:my="http://www.example.com/ns/my">
     <p:option name="initial-template" value="my:main" />
   </p:xslt2>

the component knows that the initial-template option has a QName value, 
and therefore uses the in-scope namespaces that it's passed in order to 
interpret them.

This is the same as (on the Saxon command line) doing:

   -it {http://www.example.com/ns/my}main

The problem is that if I put a pipeline wrapper around my invocation, I 
might well end up with different namespaces in scope in the invocation 
of the XSLT component (which knows that the initial-template option is a 
QName) and the invocation of the pipeline (which doesn't). For example, 
I invoke my wrapper with this:

<my:wrapper xmlns:ex="http://www.example.com/ns/bar">
   ...
   <p:option name="transform-initial-template"
             value="ex:main" />
</my:wrapper>

intending the value 'ex:main' to be interpreted with the namespace 
'http://www.example.com/ns/bar'. The definition of my:wrapper is:

<p:pipeline name="my:wrapper"
   xmlns:ex="http://www.example.com/ns/foo">
   ...
   <p:option name="transform-initial-template" />
   <p:xslt2>
     ...
     <p:option name="initial-template"
       select="$transform-initial-template" />
   </p:xslt2>
</p:pipeline>

and the in-scope namespaces on the initial-template option associate the 
prefix 'ex' with 'http://www.example.com/ns/foo', and the wrong template 
is called (or more likely an error occurs).

I guess there are three possibilities:

1. We have a way of saying that particular options are QNames when 
they're declared (and the in-scope namespaces used to interpret them 
when the component is invoked):

<p:pipeline name="my:wrapper"
   xmlns:ex="http://www.example.com/ns/foo">
   ...
   <p:option name="transform-initial-template" as="xs:QName" />
   <p:xslt2>
     ...
     <p:option name="initial-template"
       select="$transform-initial-template" />
   </p:xslt2>
</p:pipeline>

2. We use a non-QName syntax for options that are qualified names, e.g.:

   <p:xslt2>
     <p:option name="initial-template"
               value="{http://www.example.com/ns/my}main" />
   </p:xslt2>

3. We accept that it's a theoretical problem, and put a warning in the 
spec about it, but don't worry about it because it'll hardly ever 
actually be a practical problem (since people tend to be consistent in 
their use of prefixes).

I'm inclined to do the last, since with the first two the cure is worse 
than the disease (plus they're only practical with values that are 
actually QNames, not for values that are lists of QNames or XPaths or 
any other kind of value that contains QNames).

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Monday, 12 March 2007 10:27:42 UTC