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

Re: Namespace bindings

From: Alex Milowski <alex@milowski.org>
Date: Tue, 14 Aug 2007 08:32:13 -0700
Message-ID: <28d56ece0708140832m5c7c1525sb072789264992e2b@mail.gmail.com>
To: public-xml-processing-model-wg@w3.org

On 8/9/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
> 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:

I should explain how I was imaging this would 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.
>

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.

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.

Now, if you are going to select a QName value out of a document, the following
rule should handle things:

"If the 'select' attribute is used on the p:option element and the
expression resolves
to a single node, the in-scope namespaces are the in-scope namespaces of the
nearest ancestor-or-self element."

That means if you do something like:

<x:mydelete>
<p:option name="delete" select="/config/delete/@name"> ...</p:option>
</x:mydelete>

the right thing will happen in the the QName value of the 'name'
attribute of the
'delete' element will be resolved against the in-scope namespaces of
the 'delete'
element.

Finally, if you compute a QName value you'd need a way to specify the
in-scope namespaces.  I was suggesting we'd limit ourselves to the documents
against which the 'select' expression was computed.  As such, the in-scope
namespaces could just be set by another XPath expression into that same
document set via a 'namespaces' attribute.  That expression must identify an
element from which the in-scope namespaces are taken.

I suggest we allow that expression to select a set of elements and we just take
the first element returned.

The case that this leaves out is where you are computing a QName from
option values from different sources.  There I suggest we say "good
luck".  The author would have to choose a single source for the in-scope
namespaces and there might be different definitions of the same prefix.


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
Received on Tuesday, 14 August 2007 15:32:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:54 GMT