- 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