- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Thu, 20 Mar 2008 14:51:28 +0000
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: public-xml-processing-model-wg@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
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.
ht
- --
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: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFH4nnwkjnJixAXWBoRAqU0AJ40WJNRBODKrDZ7N5z7hfbmcn5LawCfUDK4
jsfxy+hWBei6N0XEQFW1gnE=
=nXqS
-----END PGP SIGNATURE-----
Received on Thursday, 20 March 2008 14:52:10 UTC