- From: Alex Milowski <alex@milowski.org>
- Date: Wed, 15 Aug 2007 07:06:10 -0700
- 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 UTC