ACTION-2008-08-28-03: the kinds of nodes that are legal for all steps

N.B. There are two change proposals herein.

We begin with the general rule in 7.0:

  In most steps which use a select expression or match pattern, any
  kind of node can be identified by the expression or pattern.
  However, some expressions and patterns on some steps are only
  applicable to some kinds of nodes (e.g., it doesn't make sense to
  speak of adding attributes to a comment!).

  It is a dynamic error (err:XC0023) if a select expression or match
  pattern returns a node type that is not allowed by the step.

The consider each of the steps in turn:

7.1.1 p:add-attribute

Must match an element and says so.

7.1.2 p:add-xml-base
7.1.3 p:compare
7.1.4 p:count
Have no select/match attribute.

7.1.5 p:delete

Can match any kind of node, so the general rule applies.

7.1.6 p:directory-list
7.1.7 p:error
7.1.8 p:escape-markup

Have no select/match attribute.

7.1.9 p:filter

Must identify an element and says so by reference to the semantics of
select on p:input.

7.1.10 p:http-request
7.1.11 p:identity

Have no select/match attribute

7.1.12 p:insert

Allows only element nodes and says so. On reflection, I think this is
correct. On some call we had a discussion about the possibility of
inserting, for example, comments before the document element. It turns
out that this isn't possible because the content to be inserted must
be a document and must, therfore, contain an element.

7.1.13 p:label-elements

Must match elements and says so.

7.1.14 p:load

Has no select/match attribute.

7.1.15 p:make-absolute-uris

Must match element or attribute nodes and says so.

7.1.16 p:namespace-rename
7.1.17 p:pack
7.1.18 p:parameters

Have no select/match attribute.

7.1.19 p:rename

Must match element, attribute, or processing instruction nodes and says so.

7.1.20 p:replace

Claims that it must match element nodes, but I don't see why.

PROPOSAL: Allow the match pattern to match element, comment,
processing-instruction, or text nodes.

7.1.21 p:set-attributes

Must match element nodes and says so.

7.1.22 p:sink
7.1.23 p:split-sequence
7.1.24 p:store

Have no select/match attribute.

7.1.25 p:string-replace

Can match any kind of node and says so.

7.1.26 p:unescape-markup

Has no select/match attribute.

7.1.27 p:unwrap

Must match element nodes and says so.

7.1.28 p:wrap

Can match element, text, processing instruction, and comment nodes and
says so.

The current text makes group-adjacent meaningless unless element nodes
are matched.

PROPOSAL: Change the description of adjacency as follows:

  Two matching nodes are considered adjacent if and only if they are
  siblings and only ignorable nodes occur between them.

  If both matching nodes are elements, then whitespace text, comment,
  and processing instruction nodes are ignorable.

  If either matching node is not an element, then only whitespace text
  nodes are ignorable.

7.1.29 p:wrap-sequence
7.1.30 p:xinclude
7.1.31 p:xslt
7.2.1 p:exec

Have no select/match attribute.

7.2.2 p:hash
7.2.3 p:uuid

Can match any kind of node and says so.

7.2.4 p:validate-with-relax-ng
7.2.5 p:validate-with-schematron
7.2.6 p:validate-with-xml-schema
7.2.7 p:www-form-urldecode

Have no select/match attribute.

7.2.8 p:www-form-urlencode

Can match any kind of node and says so.

7.2.9 p:xquery
7.2.10 p:xsl-formatter

Have no select/match attribute.

========================================

Mohamed made two other proposals in LC 016:

- That match on p:viewport can only match element nodes. This is true, but
  I don't think we have to say anything else because the text is clear that
  the matched nodes are treated as documents, so they must be elements.

- Proposal to change p:insert, but I don't think that works for the reasons
  I cited above.

I think that *at last* discharges my action!

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | There is nothing new under the sun but
http://nwalsh.com/            | there are lots of old things we don't
                              | know.--Ambrose Bierce