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

Use select for viewport too

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Fri, 03 Nov 2006 10:56:33 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <877iycr0b2.fsf@nwalsh.com>
Yesterday we decided that we'd use "select" semantics for input and
for-each, but "match" semantics for viewport. On further
consideration, I think we've made a mistake and we should use "select"
semantics for viewport as well.

I understand that viewport is different, but I don't think it's that
different. There's got to be an extra rule about only processing the
"top most" matching node, but that extra rule applies no matter which
semantic we employ for selecting nodes.

1. Users now have to understand both select semantics and match
semantics. And Jeni's already suggested that even XSLT users don't get
this very clearly.

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.

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

                                        Be seeing you,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Friday, 3 November 2006 15:56:57 UTC

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