On the interpretation of match=

Jim Fuller started a thread[1] on the xproc-dev mailing list which has
evolved into a question of spec interpretation. Jim's original
question was about p:delete, but I'm going to rephrase it using
p:rename in order to better illustrate one of the examples.

For the following discussion, assume that the this document occurs on
the default readable port:

<doc>
  <m>//item</m>
  <!-- hello world -->
  <item>an item</item>
</doc>

I think the spec is clear that both of these are valid:

  <p:rename match="//item" new-name="foo"/>

  <p:rename match="//no-such-item" new-name="foo"/>

The former renames the "item" to "foo", the latter does nothing
because there are no elements named "no-such-item".

I think the following is also clearly valid:

  <p:rename new-name="foo">
    <p:with-option name="match" select="/doc/m"/>
  </p:rename>

The value of the match attribute is taken from the string-value of the
/doc/m node which is "//item" so this step is functionally the same as
the very first example above.

I think it's also clear that the following is invalid:

  <p:rename match="/doc/node()[4]" new-name="foo"/>

The matched node is a comment and rename cannot target comments.

But what about this example:

  <p:rename new-name="foo">
    <p:with-option name="match" select="/doc/a"/>
  </p:rename>

There's some debate on the xproc-dev thread about it, but after
looking through the XSLT 2.0 spec, I'm pretty confident that it's an
error.

I think the shortest argument why is that the BNF for an XSLT 2.0
Pattern[2] (which we call an XSLTMatchPattern and still need to cite a
little more carefully) cannot be empty.

                                        Be seeing you,
                                          norm


[1] http://markmail.org/message/otaebbniqetguf6w
[2] http://www.w3.org/TR/xslt20/#dt-pattern

-- 
Norman Walsh <ndw@nwalsh.com> | A moment's insight is sometimes worth a
http://nwalsh.com/            | life's experience.--Oliver Wendell
                              | Holmes