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

Re: Use select for viewport too

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 03 Nov 2006 16:39:15 +0000
Message-ID: <454B70B3.3010204@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Hi Norm,

Norman Walsh wrote:
> 2. What's more, they have to translate between them if they want to
> apply similar processing with for-each and viewport. Consider a
> pipeline that makes chunks out of a book:
>   <p:for-each select="//chapter|//chapter/section" ...>
> Now the pipeline author wants to use a viewport to build the
> ToC, replacing each chunked part with some sort of link. They
> can't just use the select expression, they have to do something
> else, like:
>   <p:viewport match="chapter|section[parent::chapter]" ...>
> I think that's a disaster.

Users can still write

   <p:viewport match="//chapter|//chapter/section" ...>

That's a legal pattern. The fact that the // doesn't do anything doesn't 
mean the users can't use it.

As I discussed in my last mail, with the constraints we have on select 
expressions (must have a root node as the context node; must return an 
element), there are relatively few expressions that don't map 
immediately on to patterns.

I suppose one thing that might be surprising is that:

   <p:for-each select="chapter" ...>

will identify the <chapter> document element, whereas

   <p:viewport match="chapter" ...>

will identify <chapter> elements throughout the document (well, assuming 
  that they don't have an ancestor <chapter> element, that is).

> 3. We now require implementors to support both kinds of semantics
> which, with my implementors hat on, is an unpleasant burden. I have a
> library for doing select, I plan to do some analysis to stream some
> expressions, but short of linking to an XSLT impl or writing my own
> impl from scratch, I don't know how to get match semantics

Patterns are defined in the XPath spec in terms of expressions, so it 
shouldn't be too much of a burden to implement it. Add a "//" at the 
front; evaluate it as an expression; see if the node that you're 
examining is in the node set that you got.

But overall I think I agree that it makes more sense to use expressions 
all over (though I'm still going to argue that the attribute on 
<p:viewport> needs to be called something other than 'select' to reflect 
its different semantic).


Jeni Tennison
Received on Friday, 3 November 2006 16:39:37 UTC

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