- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Mon, 27 Aug 2007 15:31:00 +0100
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
4.3.1
Same change to 'Note to implementers' as for 4.2.1
4.3.2
"add an hr element before all"
-->
"add an hr element at the beginning of all
4.4
"same number outputs" --> "same number of outputs"
4.6.1
Major confusion wrt prefixes (c: vs err:) and links (c:error in the
first liine of 4.6.1.2 links to the p:error section!)
I have some vague memory of a decision to abandon a namespace and
collapse names from that namespace into some other one -- was it the
err: namespace? If so, not only do the uses of err: in this section
and in 4.6.2 need to be changed, but also the entry for err: should
be removed from section 3.1
4.6.2
Examples --> Example
(oops, and in 4.1 -- 4.5 subsections as well . . .)
4.7
As long as we leave the tableau for them here, we can't say
_nothing_ about other-compound-steps! I would prefer to see them
removed from this section (see previous discussion), since they have
to be extensions, and as such they don't have to conform to our
syntax at all (note for instance that as written the production
given here would rule out a p:choose-type extension,
e.g. ipfx:case).
At the very least, we need something along the lines of "The
'other-compound-step' tableau is included above as an illustrative
place-holder for future expansion of the language, which might be
explored via extensions in the first instance."
5.1.1
I think it's worth including something along the lines of
"It is a *static error* if the declaration of a document input port
inside a p:declare-step contains bindings; document input port
declarations must be empty unless they are declaring _and_ binding
an input port for a p:pipeline."
5.1.2
The wording here for ruling out content need not mention 'default',
as it's never been suggested that there _was_ a default:
"It is a static error (err:XS0035) if the declaration of a
parameter input port contains bindings; parameter input
port declarations must be empty."
------
I think it's a mistake to use the concept of 'extension attributes'
for elements in the c: namespace -- it's not at all obvious what
specification of extension namespaces should be appealed to (at
runtime, note), to determine this. Wouldn't it be easier to say,
for c:parameter:
"Any namespace-qualified attribute names that appear on the
c:parameter element are ignored; it is a *static error* for any
_un_qualified attributes other than 'name', 'namespace' or 'value'
to appear."
and for c:parameter-set, either the same, or just:
"Any attribute names that appear on the c:parameter element are
ignored"
5.4
The primary stuff should be brought in to line with 5.1.1 (and 2.3):
"The primary attribute is used to identify the primary output
port. An output port is a primary output port if primary is
specified with the value 'true' or if the step has only a single
output port and primary is not specified. It is a static error
(err:XS0014) to specify that more than one output port is the
primary."
5.5
A note about security implications?
5.7
"Options names" --> "Option names"
5.7.1.1
Sigh, this highlights a general problem. We use 'QName' all over
this spec., and sometimes we specify in detail where the namespace
bindings come from to expand them (most notably for option values,
but also, e.g. for c:parameter names), in which case one should
understand QName to mean "QName as specified in XML Namespaces 1.1".
But in other places, e.g. here, we just say "must be a QName".
_Either_ we should specify where the namespace bindings come from,
_or_ we should say "must be a QName as specified in XML Schema 1.0"
(but that wouldn't _really_ do that job, because the Schema spec. is
weak here).
I guess I think we should make QName a defined term, use it
everywhere, and define it to mean "must be a QName as specified in
XML Namespaces 1.1. If unprefixed, in no namespace. If prefixed,
prefix *must* be bound in the in-scope namespaces of the containing
element, unless some other source of namespace bindings is
specified." and specify one or two static errors to use for failures
of the two "*must*"s.
------
"to specify that the option is both required and has a default
value."
-->
"to specify that an option is both required and has a default
value."
5.7.1.3
"If a 'select' expression is given, ..."
Should reference 2.8.1, and mention variable references, e.g.:
"If a 'select' expression is given, it is evaluated as an [XPath
1.0] expression using the Processor XPath context as defined above
in section 2.8.1. The [XPath 1.0] string value of the expression
becomes the value of the option. Since all in-scope options are
present in the Processor XPath context as variable bindings,
'select' expressions may refer to the value of in-scope options by
variable reference. It is a static error (err:XS0019) if a
variable reference uses a QName that is not the name of an in-scope
option."
-----
"If the value of an option is a constant, and no namespace bindings
are necessary, its value may also be specified on the parent step
as specified in Section 4.7.1, 'Syntactic Shortcut for Option
Values'."
Whoa -- I didn't agree to "and no namespace bindings are necessary" !
Why can't we say that in that case the in-scope namespace bindings
are used? That's the default for <p:option value='...'/>, right?
Or is what is meant
"If the value of an option is a constant, and no namespace bindings
other than those in-scope on the parent step are necessary, its
value may also be specified on the parent step as specified in
Section 4.7.1, 'Syntactic Shortcut for Option Values'."
[out-of-band conversation with Norm suggests that is indeed what was
meant, so this is just editorial after all]
5.7.2
Combine the paras about 'select' before and after the tableau to give
a para. identical to the one above for options, s/option/parameter/.
5.7.3
"The p:namespaces element can be used to provide explicit
bindings."
-->
"The p:namespaces element can be used as a child of p:option or
p:parameter to provide explicit bindings."
-----
I find the discussion of what bindings a p:namespaces element
contributes somewhat unclear. How about replacing the two paras
which are there at present with the following:
"The namespace bindings specified by a p:namespaces element are
determined as follows:
1) All the bindings defined by explicit namespace attributes
(other than 'xmlns') on the p:namespaces element itself are
used;
2) If the 'option' attribute is specified, it *must* contain the
name of a single in-scope option. The namespace bindings
associated with that option are used;
3) If the 'element' attribute is specified, it *must* contain an
XPath expression which identifies a single element node (the
input binding for this expression is the same as the binding
for the p:option or p:parameter which contains it). The
in-scope namespaces of that node are used;
4) The except-prefixes attribute can be used to exclude one or
more namespaces from the set determined by the previous three
bullets. The value of the except-prefixes attribute *must* be a
sequence of tokens, each of which *must* be bound to a
namespace in the in-scope namespaces of the p:namespaces
element. All bindings of prefixes to each of the namespaces
thus identified are excluded."
and then the XS0005 and XS0041 error specs.
5.10
'Name' is overloaded -- I think at the very least we need to change
"It is a dynamic error (err:XD0012) to import more than one
pipeline with the same name or type (either directly or within a
library)."
- -->
"It is a dynamic error (err:XD0012) to import more than one
pipeline with the same expanded name (either directly or within a
library)."
which sort of implies a definition further up:
"The [expanded name] of a pipeline is the expanded name denoted by
its type, if it has one, otherwise the expanded name specified by
the namespace of its containing pipeline-library and its name."
5.11
I'm unhappy with a perhaps-unintended consequence of the way output
ports on compound steps are handled here. Seems to me this is a
perfectly good p:for-each:
<p:for-each name="saveThem">
<p:output port="result">
<p:pipe step="saveThem" port="current"/>
</p:output>
<p:save>
<p:option name="href" select="concat("file:/tmp/chapter",
p:iteration-position(),
".xml")/>
</p:save>
<p:for-each>
I would propose therefore that we change the discussion of
constraints on p:pipe binding to read as follows:
"In all cases except the p:output of a compound step, it is a
static error (err:XS0022) if the port identified by a p:pipe is not
in the readable ports of the environment of the step that contains
the p:pipe. [unchanged]
"It is a static error (err:XS0022) if the port identified by a
p:pipe in the p:output of a compound step is not in the readable
ports of the _inherited environment_ for steps contained in that
compound step.
"In other words, the output of a compound step is treated like the
input of a new final step in its subpipeline. All other bindings
must be to ports that are already readable in the current
environment."
I prefer this not only because it fixes what I think is a bug, but
also because it makes the defaulting of compound outputs follow
naturally.
5.12
"It is a static error (err:XS0024) if the content of the p:inline
element is not a well-formed XML document."
How could any processor ever detect this error?
5.13
"The parser which the p:document element employs must be conformant
to Namespaces in XML.
-->
"The parser which the p:document element employs must be conformant
to [Namespaces 1.1]."
6
I didn't check this section, on the assumption that its prose is
autogenerated from the locus of first use. . . Maybe that's false?
7
"The base URI of the output is the base URI of input document
unless the step's process explicitly sets and xml:base attribute or
the step's description explicitly states how the base URI is
constructed."
-->
"The base URI of the output is the base URI of the step's primary
input document unless the step's process explicitly sets an
xml:base attribute or the step's description explicitly states how
the base URI is constructed."
[one substantive change and one typo]
Is it in fact the case that all builtin steps have a primary input or
specify their output's base URI? Should we add something such as
"If the step has no primary input document, its description *must*
state how the base URI is constructed."
-----
"When a step uses an XPath from an option value, the XPath context
is as defined in Section 2.8.1, 'Processor XPath Context'."
-->
"When a step uses an XPath from an option value, the XPath context
is as defined in Section 2.8.2, 'Step XPath Context'.
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)
iD8DBQFG0uAkkjnJixAXWBoRAjChAJ9U3gmUTMRCdHnwPatMjZNK2OwjEwCfZGST
WNs4Oirrx734fdkPU5qvlwo=
=Aohu
-----END PGP SIGNATURE-----
Received on Monday, 27 August 2007 14:31:12 UTC