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

Re: Namespace bindings

From: Alex Milowski <alex@milowski.org>
Date: Wed, 15 Aug 2007 07:06:10 -0700
Message-ID: <28d56ece0708150706p6c750b15yba07b37638f3b66f@mail.gmail.com>
To: public-xml-processing-model-wg@w3.org

On 8/15/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
> Alex Milowski wrote:
> > On 8/9/07, Jeni Tennison <jeni@jenitennison.com> wrote:
> >> 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.
>
> Sure.
>
> > 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.
>
> Err, no. Because the x:mydelete pipeline looks like:
>
> <p:pipeline xmlns:p="..." xmlns:x="..."
>              type="x:mydelete">
>    <p:option name="delete" required="yes" />
>
>    <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>
>
> The $delete option in x:mydelete gets set to "h:div" including the
> namespace binding {"h": "http://www.w3.org/1999/xhtml"}, fine. But when
> the $match option in p:delete gets set, it's set to "h:div" with the
> namespace binding {"html": "http://www.w3.org/1999/xhtml"}. There's no
> binding for the "h" prefix, so the step fails.
>
> I don't see how your proposal handles this example (option value bound
> to option value), and I think think is going to be the most common case.

I'm suggesting that $delete refers to an option value.  For this to work, an
option value must be its own type (a variant) that converts to a string/etc.
but carries with it the in-scope namespaces.

A reference to $delete refers directly to an option value and so you
can propagate forward the in-scope namespaces.

An expression like:

   concat('foo:',$delete)

converts the option value to a string and so the in-scope namespaces are lost.

Implementations that use a standard XPath (e.g. JAXP) would have to inspect
the p:option's select for single variable references and do the right thing with
in-namespaces and option values.  If you have your own XPath implementation,
you can just define a variant type with the proper conversions and
everything works out quite nicely.

-- 
--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 Wednesday, 15 August 2007 14:06:15 GMT

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