Re: Namespace bindings

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | Norman Walsh wrote:
> |> Do we expect the following pipeline to work?
> 
> The consensus on the 9 Aug 2007 call was, "no".

My fundamental goal is to allow people should be able to construct 
pipelines that act as wrappers around built-in steps. Namespaces are 
something that people find hard to get right -- authors will assume a 
fixed set of prefix-uri bindings and find their pipelines break when 
they're called with a different set of prefix-uri bindings. We need to 
help users get it right.

I really don't think it's sufficient to say "you lose" when it comes to 
namespaces, because it makes it impossible to write pipelines that take 
QNames or XPaths as options. Given how many of the built-in pipelines 
take one or both, I think it's ludicrous to assume that pipeline authors 
aren't going to want to write them.

> | Yes, I think we should support this too.
> 
> The whole question of merging namespace bindings taken from variable
> references used in XPath expressions used to compute option values was
> viewed with great suspicion.

Yes, I don't like that either. I'd far rather an explicit way to pass in 
the namespace bindings for the step/option, and Alex's suggestion gets 
part of the way there. But it doesn't address the case:

> <p:pipeline xmlns:p="...">
>   <p:option name="delete" value="html:div"
>             xmlns:html="http://www.w3.org/1999/xhtml"/>
> 
>   <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>
> 
> In other words, don't do that. If you have control of the situation,
> make the namespaces work.

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.

What about having a <p:namespaces> element inside <p:option> that allows 
you to explicitly indicate any number of sets of namespaces that should 
be used. The optional 'from' attribute can hold either a variable 
reference (refering to an option) or an absolute location path (refering 
to context node). If it's not specified then you get the in-scope 
namespaces on the <p:namespaces> element itself. If more than one 
<p:namespaces> is specified, then the last binding for a given prefix 
gets used.

So:

   <p:option name="delete" value="h:div"
     xmlns:h="http://www.w3.org/1999/xhtml" />

is a shorthand for:

   <p:option name="delete" value="h:div"
     xmlns:h="http://www.w3.org/1999/xhtml">
     <p:namespaces />
   </p:option>

and:

   <p:option name="delete" value="h:div">
     <p:namespaces xmlns:h="http://www.w3.org/1999/xhtml" />
   </p:option>

would also work. When referencing another option, you can do:

   <p:option name="match" select="$delete">
     <p:namespaces from="$delete" />
   </p:option>

When referencing a node from a configuration input, you can do:

   <p:option name="match" select="/commands/delete/@match">
     <p:namespaces from="/commands/delete" />
     <p:pipe step="load-commands" port="result"/>
   </p:option>

And if you're doing some kind of combination, you can specify several, 
in whatever precedence order you choose:

   <p:option name="match"
     select="concat('html:body/', /commands/delete/@match)">
     <p:pipe step="load-commands" port="result" />
     <p:namespaces from="/commands/delete" />
     <p:namespaces xmlns:html="http://www.w3.org/1999/xhtml" />
   </p:option>

We *could* attempt to default a <p:namespaces> when the select attribute 
holds something that could legitimately go in the 'from' attribute of 
<p:namespaces>. Something like: if no <p:namespaces> is provided, and 
the <p:option> uses a select attribute, a <p:namespaces> is created 
whose from attribute contains the value of the select attribute. It is 
an error if the resulting <p:namespaces> element is invalid (ie the from 
attribute holds neither a variable reference nor an absolute location 
path). If the <p:option> has a value attribute, the generated 
<p:namespaces> has no from attribute.

Cheers,

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

Received on Thursday, 9 August 2007 20:27:13 UTC