Re: Use select for viewport too

Norman Walsh wrote:
> 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.

Yes, that's a problem for novice users.  If they don't understand that
difference, they are going to have trouble with all kinds of things
in our specification.  The better question is whether, given they
take the time to understand, will it make sense.

When I taught XSLT, I described match patterns in terms of a tree
walk and people usually got it.  Putting it into practice still took
some effort.  Given that, I think we're just going to lose those
users when they get to things like viewport regardless of
whether they are full XPath expressions or match patterns.  ...but
that's just a guess and none of us will know until we actually
have users.

> 
> 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]" ...>

No, they don't.  Those same XPath expressions are match patterns and
so they can just write:

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

and it makes more sense because "outer most" can be described as
"first match and don't traverse descendants".

> 
> I think that's a disaster.

disaster avoided...

IMHO, the whole point of viewport is to apply transformation
semantics to very large documents where such things would be
difficult or impossible to do otherwise.  Here I think it is important
to convey to the user that they are matching subtrees for
those operations.

The subset of match patterns that do not stream is a much, much
smaller subset than general XPath expressions.  As such, we've
helped the use reduce the possible expressions to those that
are more likely to stream and provide efficient support for
large documents.

...and before someone says it: yes, they can apply the same
rules to general XPaths that they might to match patterns to
determine whether the XPath they are about to use in a viewport
is going to cause streaming to fail.

All I'm saying is that the model here *is* matching subtrees.

--Alex Milowski

Received on Friday, 3 November 2006 16:52:55 UTC