- 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, norm -- Norman Walsh XML Standards Architect Sun Microsystems, Inc.
Received on Friday, 3 November 2006 15:56:57 UTC