Re: select in for-each and iteration-source

/ Norman Walsh <ndw@nwalsh.com> was heard to say:
| / Innovimax SARL <innovimax@gmail.com> was heard to say:
| | On 6/6/07, Norman Walsh <ndw@nwalsh.com> wrote:
| [...]
| |> No, I don't believe that's the case. If it was, then 'select' wouldn't
| |> have the semantics of an XSLT 'select' and I'd want to change the
| |> attribute's name.
| |>
| |> We decided to use 'match' on p:viewport where it's really important
| |> not to process elements more than once. Everywhere else where we've
| |> used select=, I assume we're using the standard XPath/XSLT select
| |> semantics.
| |
| | I agree with your analysis but I'm sorry : THAT'S NOT WHAT IS WAS
| | WRITTEN IN THE SPEC !
|
| Bah! Fire the editor!

But seriously. As a user and an implementor, despite the fact that I
have not only read the spec several times, I actually *wrote those
words*, I think it's absolutely clear that the semantics implied by
naming the attribute 'select' are so overwhelming that if we don't
intend them, we must rename this attribute.

Though I'd prefer to simply remove it.

| | [[
| | The select expression, if specified, applies the specified [XPath 1.0]
| | select expression to the document(s) that are read. Each node that
| | matches is wrapped in a document and provided to the input port. After
| | a node has been matched, its descendants are not considered for
| | further matching; a node is passed at most once as input. In other
| | words,

Do we have a use case that actually justifies this complexity?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.