W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > August 2007

Re: First stab at p:namespaces

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 20 Aug 2007 16:28:03 +0100
Message-ID: <46C9B303.20408@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | 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.

*May* point to a single in-scope option *or* a node from a document.

> | 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 was the idea.

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

As you like. Probably 'option' and 'element' would be better than 
'option' and 'from'. The '$' wouldn't be necessary before the option 
name if it has its own attribute, but I can't decide whether it's more 
confusing to have it there or not to have it there.

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


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

I think we say it for QNames that are used in XProc (like the value of 
the type attribute), but this section has to say it for namespace 
bindings passed into options -- the context is different here.

Like Mohamed suggested, we should provide a way to ignore other 
namespace bindings, particularly if we're going to error if there are 
any clashes. I don't want my binding for the XProc namespace to clash 
with a binding from a configuration document just because we happened to 
both use 'p' as the prefix.

I'm not sure if we can reuse 'ignore-prefixes' for this, though, 
particularly as (as currently defined) you can't use 'ignore-prefixes' 
to ignore the XProc namespace or namespaces that you use for steps, when 
these are precisely the namespaces that you're most likely to want to 
ignore when passing around option values.

OPTION 1: have a general rule that the ignorable namespaces (given by 
'ignore-prefixes'), the XProc namespace and namespaces used by imported 
pipelines or in which an atomic step has been declared are all ignored 
when creating namespace bindings for options from the context of the 
<p:namespaces>. And then having a 'prefixes' attribute that enables you 
to add them back in again.

That would mean if I did:

   <p:option name="match" value="p:pipeline" />

I'd get an error, and I would have to do:

   <p:option name="match" value="p:pipeline">
     <p:namespaces prefixes="p" />

to include the 'p' prefix in the set passed into the option.

OPTION 2: when getting namespaces from either the <p:option> or a 
selected element, we could have an 'except-prefixes' attribute on the 
<p:namespaces> element that lists prefixes that shouldn't be included. 
So I could do:

   <p:option name="match" value="p:pipeline" />

and it would work, but if I wanted to limit the possibility of clashes 
when doing:

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

(in case the match option has 'p' bound to something different) then I 
would have to do:

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

The second option looks better to me as the first is likely to lead to 
errors more often.


Jeni Tennison
Received on Monday, 20 August 2007 15:28:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:44 UTC