Re: First stab at p:namespaces

Norman Walsh wrote:
> With two days of on-site stuff keeping me busy, I didn't make as much progress
> as I hoped, but I have rewritten 5.7, especially 5.7.3
> 
>   http://www.w3.org/XML/XProc/docs/langspec.html#opt-param-bindings
> 
> Comments (you got it totally wrong), suggestions (can't you make it sensible), etc. 
> most welcome, as always.

Technical things:

You got it totally wrong! ;)

Six (!) technical things, I think:

1. the <p:namespaces> elements live inside the <p:option> element, so 
that you can do per-option namespace bindings. I think the text gets 
this right, but the examples get it wrong.

2. In my proposal for this, if the from attribute on <p:namespaces> 
holds a variable reference, the namespaces come from the option named by 
the variable reference. So in the example given you could do:

<p:pipeline type="ex:delete-in-div"
             xmlns:p="http://www.w3.org/2007/03/xproc"
             xmlns:ex="http://example.org/ns/ex"
             xmlns:h="http://www.w3.org/1999/xhtml">
<p:option name="match" required="yes"/>

<p:delete>
   <p:option name="match" select="concat('//h:div/',$match)">
     <p:namespaces /> <!-- this inherits the 'h' binding -->
     <p:namespaces from="$match" />
   </p:option>
</p:delete>

</p:pipeline>

rather than having to do all the messing around with p:to-xml. (I think 
that if we have this, there's no desperate need for the p:to-xml step. 
Which is a good thing.)

Also, I suggest that if it evaluates to a node-set, we just use the 
first node to provide the namespace bindings, and ignore the fact that 
there are other nodes in the mix, but I'm not strenuously opposed to 
having it an error if more than one node is selected. You need to 
provide an error code for the case when the from attribute doesn't hold 
a variable reference, and evaluates to something other than a node-set.

3. I think authors should be able to use the order of the <p:namespaces> 
elements to determine the precedence of the different bindings. But to 
do that, it can't be an error if there's more than one namespace binding 
  for the same prefix. Rather, in the event of a conflict, the *last* 
namespace binding for a given prefix needs to be the one used. (This is 
particularly important if default namespaces are included; see point 6.)

4. It will help authors enormously if the defaults on the namespaces 
used are based on how the option/parameter gets set, namely:

   (a) if the select attribute is used to set the option/parameter, and 
it contains a VariableReference[XPath], then the namespace bindings from 
the referenced option are used.

   (b) if the select attribute is used to set the option/parameter, and 
it evaluates to a node-set then the in-scope namespaces from the first 
node in the selected node-set (or, if it's not an element, its parent) 
are used.

   (c) otherwise, the in-scope namespaces from the <p:option> itself are 
used.

5. I don't think the <p:namespaces> element should have any content: I 
can't imagine that you'd want to use the namespaces from one document to 
interpret the value of a node from another, and that's the only reason I 
can see to have it. The context for the expression used in the from 
attribute should come from the context of the expression used in the 
enclosing <p:option>/<p:parameter>. (You need to say this, and point to 
the relevant section, particularly to indicate what variable bindings 
are in-scope for the XPath the from attribute contains.)

6. We need to say something about the default namespace. I'm inclined to 
say that options never have a default namespace (which means that you 
have to always give a prefix to QNames passed as option values).


Editorial thing:

It says

  "In this case, neither the bindings on the option passed to 
ex:delete-in-div nor the bindings on the option ultimately passed to 
p:delete are correct."

I think it would be clearer to say

  "In this case, the match option passed to the <p:delete> step needs 
*both* the namespace binding of 'h' specified in the ex:delete-in-div 
pipeline definition *and* the namespace binding of 'html' specified in 
the match option on the call of that pipeline. It's not sufficient to 
provide just one of the sets of bindings."

Also, it might help make the exposition clearer if the option in 
ex:delete-in-div were called something like "div-child" rather than 
"match" (since that's the same name as is used for the option on p:delete).


Little thing:

In the "more complicated" example, you have

    <p:option name="match" select="concat('//h:div/',$match)"/>

Patterns should never begin with a '//'; please remove it :)


Cheers,

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

Received on Saturday, 18 August 2007 20:42:53 UTC