- From: Norman Walsh <ndw@nwalsh.com>
- Date: Mon, 27 Aug 2007 13:29:56 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2sl64ansb.fsf@nwalsh.com>
/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 4.3.1
|
| Same change to 'Note to implementers' as for 4.2.1
Ok.
| 4.3.2
|
| "add an hr element before all"
| -->
| "add an hr element at the beginning of all
Ok.
| 4.4
|
| "same number outputs" --> "same number of outputs"
Ok
| 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
The error vocabulary has been moved to the c: namespace, but the err:
namespace has been retained to identify static and dynamic errors.
| 4.6.2
|
| Examples --> Example
| (oops, and in 4.1 -- 4.5 subsections as well . . .)
Ok.
| 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."
Well, I removed the tableaus. Maybe that helps?
| 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."
Ok
| 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."
Ok.
| 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"
I see your point. I'm happy to make this change.
| 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."
Done.
| 5.5
|
| A note about security implications?
Such as?
| 5.7
|
| "Options names" --> "Option names"
Fixed.
| 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.
Do you mean "XML Namespaces 1.1" literally, or do you mean "XML Namespaces
1.0 or XML Namespaces 1.1, as appropriate"?
| ------
|
| "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."
Ok.
| 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."
Ok.
| "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]
Yes. Fixed.
| 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/.
Ok.
| 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."
Fixed.
| 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.
Ok.
| 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)."
Ok.
| 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."
Done.
| 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>
That makes my brain hurt. Output ports bind to step outputs. If you
want that, stick in p:identity step that reads the input and produces
an 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?
By looking to see if p:inline has two or more top-level element children.
| 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]."
See earlier question about NS 1.0 vs. NS 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?
Egad! Yes! That's definitely true!
| 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]
Fixed.
So we mean for a xml:base attribute on the root element to change the
base URI *of the document that contains that element*? That's not what
xml:base does ordinarily.
| 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."
Alex?
| "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'.
Fixed.
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | It is better to waste one's youth than
http://nwalsh.com/ | to do nothing with it at all.--Georges
| Courteline
Received on Monday, 27 August 2007 17:30:06 UTC