Re: Uncle! New alternate draft [comments on some of section 5]

Hash: SHA1

5.1.1    "and my provide" --> "and may provide"

5.1.1    'provides a single document, but

           <p:identity name="irrelevant">'

         So irrelevant that it should be removed, I think. . .

5.1.2    "Most stylesheets don't bother" --> "Most steps don't bother"

5.1.3    "It is a static error (err:XS0023) for a p:pipe to appear in
          a default binding."  Why is this necessary?  The tableau for
          input declarations doesn't include p:pipe, so XS0044 does
          the necessary, doesn't it?

5.4      "A p:output identifies an output port, optionally declaring it, if
         necessary." --> "A p:output declares an output port,
         optionally binding and input for it, if necessary."
5.4      "It is a static error (err:XS0013) if the port given does not
         match the name of an output port specified in the step's
         declaration."  Either I'm confused, or this (and XS0013)
         should be removed.  You _can't specify_ an output on an
         atomic step, which is the only case where a separate
         declaration is availale to compare it to.

5.7.2    The discussion of defaults is not quite right yet, I don't
         think.  It appears to me to contradict itself about whether
         the values of variables which are in scope for a step type
         instance which needs a default are available or not.  Here's
         my proposed rewrite, assuming xsl:param is the appropriate

    If an option is not declared to be required, it may be given a
    default value. The value can be specified in two ways: with a
    select or value attribute.

    It is a static error (err:XS0017) to specify that an option is
    both required and has a default value.

    If a value attribute is specified, its literal content supplies the
    default value of the option.

      name = QName
      value = string />

    If a select attribute is specified, its actual value supplies the
    default value of the option, which may differ from one instance of
    the step type to another.

      name = QName
      select = XPathExpression />

    The select expression is only evaluated when its actual value is
    needed by an instance of the step type being declared. In this
    case, it is evaluated as described in Section 2.7.3,
    p:with-option, except that the *context node* is an empty document
    node and the *in-scope namespaces* are the in-scope namespaces of
    the p:option itself.

    When XPath 1.0 is being used, the string value of the expression
    becomes the value of the option; when XPath 2.0 is being used, the
    value is an untypedAtomic.

5.7.3    Similarly, the second para after the tableau in this section
         needs to change to something like the following:

         Also, retrospectively, we need to add bindings back in to the
         Environment and defining *in-scope options* and *in-scope
         variables* with reference thereto -- see separate message.

    The values of options for a step *must* be computed in the order
    determined by the step's _signature_.

    If a select expression is given, it is evaluated as an XPath
    expression using the context defined in Section 2.6.1, Processor
    XPath Context, for the surrounding step, with the addition of
    variable bindings for all options whose declarations precede its
    declaration in the surrounding step's _signature_.

    When XPath 1.0 is being used, the string value of the expression
    becomes the value of the option; when XPath 2.0 is being used, the
    value is an untypedAtomic.

- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail:
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Thursday, 20 March 2008 14:52:10 UTC