Re: First stab at p:namespaces

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| You got it totally wrong! ;)

Heh. I asked for that, didn't I?

| 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.

Yes, typo in the examples. Fixed.

| 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.)

So the 'from' attribute must point to a single in-scope option.
Ok, that does seem to remove the need for p:xml-to which was a pretty hard
step to explain, so I'm in favor.

| Also, I suggest that if it evaluates to a node-set, we just use the

Now I'm confused. If it's a single variable reference you want to use the
namespace bindings on the named option, but if it's some other expression
you want to use the namespace bindings on the element selected?

That seems like an awkward set of semantics. If we want both, then I think
I'd prefer two attributes.

  <p:namespaces option="$match"/>
  <p:namespaces from="/path/to/foo"/>

| 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.

Indeed.

| 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.)

We could do that. I considered it. Trouble is, if there are conflicts,
I don't see how the result can *ever* be the right answer. If I pass
h:div to you with one binding and you decide to override that binding
with a different one, you're not going to do what I expected.

I think it should be an error. At least in V1.

| 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.

Complex, but I suppose you're right.

| 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.)

Yes, I think that's right.

| 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).

Yes. I thought we said that.

| 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."

Yep.

| 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).

Yep.

| 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 :)

Done!

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | People say law but they mean wealth.--
http://nwalsh.com/            | Emerson