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

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 5.1.1    "and my provide" --> "and may provide"

Fixed.

| 5.1.1    'provides a single document, but
|
|            <p:identity name="irrelevant">'
|
|          So irrelevant that it should be removed, I think. . .

Right.

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

Fixed.

| 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.1.3 is in the wrong place; it should be at the end of 5.1.1.

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

Ok.

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

Right. Wow, that's been hanging around for a few drafts, eh?

| 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
|          model:
|
|     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.
|
|     <p: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.
|
|     <p:option
|       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.

Ok. But I also left in these two paragraphs because I think they make
an important point:

<para><error code="S0019">It is a <glossterm>static error</glossterm>
if the <tag class="attribute">select</tag> expression contains a
variable reference that uses a QName that is not the name of an
in-scope option.</error></para>

<para>Note that because the in-scope options and variables of a
declared step are initially empty, the context in which the instance
occurs can have no bearing on the default value of any options. Only
the values of preceding options can be referenced from the select
expression.</para>


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

I don't think you've sent that message yet.

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

I think I did the right thing. I could be wrong. :-/

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The offhand decision of some
http://nwalsh.com/            | commonplace mind high in office at a
                              | critical moment influences the course
                              | of events for a hundred years.--Thomas
                              | Hardy