Re: Namespace bindings

Alex Milowski wrote:
> On 8/15/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>> Alex Milowski wrote:
>>> On 8/9/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>>>> The author of this pipeline can't just make the namespaces work. If the
>>>> pipeline was called with:
>>>>
>>>> <x:mydelete>
>>>>    <p:option name="delete" value="h:div"
>>>>      xmlns:h="http://www.w3.org/1999/xhtml" />
>>>> </x:mydelete>
>>>>
>>>> then the pipeline would fail to do what it was supposed to do.
>>>> Fortunately it would give an error because of the unbound prefix, so I
>>>> guess this isn't as dreadful as it could be, but it's still impossible
>>>> to work around, and it makes pipelines that take options that are XPaths
>>>> or QNames unviable.
>>> The core of the idea is that every option value has a set of in-scope namespaces
>>> associated with it.  By default, the in-scope namespaces are those of the
>>> p:option element where the value was set.
>> Sure.
>>
>>> For the above example:
>>>
>>> <x:mydelete>
>>> <p:option name="delete" value="h:div" xmlns:h="http://www.w3.org/1999/xhtml"/>
>>> </x:mydelete>
>>>
>>> that's going to work fine because the 'h' prefix is exactly what the
>>> author thinks
>>> it should be.
>> Err, no. Because the x:mydelete pipeline looks like:
>>
>> <p:pipeline xmlns:p="..." xmlns:x="..."
>>              type="x:mydelete">
>>    <p:option name="delete" required="yes" />
>>
>>    <p:delete>
>>      <p:input port="source">
>>        <p:inline>
>>          <html xmlns="http://www.w3.org/1999/xhtml">
>>          <head>...</head>
>>          <body>
>>            <h1>Delete My Divs</h1>
>>            <div>
>>              ...
>>            </div>
>>          </body>
>>        </p:inline>
>>      </p:input>
>>
>>      <p:option name="match" select="$delete"
>>                xmlns:html="http://www.w3.org/1999/xhtml"/>
>>    </p:delete>
>> </p:pipeline>
>>
>> The $delete option in x:mydelete gets set to "h:div" including the
>> namespace binding {"h": "http://www.w3.org/1999/xhtml"}, fine. But when
>> the $match option in p:delete gets set, it's set to "h:div" with the
>> namespace binding {"html": "http://www.w3.org/1999/xhtml"}. There's no
>> binding for the "h" prefix, so the step fails.
>>
>> I don't see how your proposal handles this example (option value bound
>> to option value), and I think think is going to be the most common case.
> 
> I'm suggesting that $delete refers to an option value.  For this to work, an
> option value must be its own type (a variant) that converts to a string/etc.
> but carries with it the in-scope namespaces.

In other words, you have to look at the syntax of the select attribute 
and see if it's a single variable reference, in which case the namespace 
bindings are set to the namespace bindings of the referenced option. 
Which is what I said originally. That wasn't in your proposal, which is 
why I was confused. Looks like we're in agreement.

> A reference to $delete refers directly to an option value and so you
> can propagate forward the in-scope namespaces.
> 
> An expression like:
> 
>    concat('foo:',$delete)
> 
> converts the option value to a string and so the in-scope namespaces are lost.

OK. If we don't offer any help with values created by concatenation, I'd 
like to have a component like:

<p:declare-step type="p:to-xml">
   <p:option name="value" required="yes" />
   <p:output name="result" />
</p:declare-step>

that takes a 'value' option and creates a <c:result> element whose value 
is the value of the 'value' option *and* that has namespace bindings 
that reflect the namespace bindings on the option.

That will at least provide *a* (fairly convaluted) means of constructing 
namespace bindings for options when their values are created through 
concatenation.

(It would also be helpful to have steps that create elements with prefix 
and uri attributes that reflect namespace bindings on a given element, 
and that turn such elements bank into namespace bindings. But that's 
something that people can create their own steps to do using XSLT; it 
doesn't have to be in the core.)

Cheers,

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

Received on Wednesday, 15 August 2007 20:06:30 UTC