- From: Norman Walsh <ndw@nwalsh.com>
- Date: Tue, 18 Mar 2008 15:06:39 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m263vj97i8.fsf@nwalsh.com>
/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say: | 2.2 "All atomic steps are defined by a p:declare-step. The | declaration of an atomic step defines the input ports, output | ports, and options of all steps of that type." --> "All | atomic step types are defined by a p:declare-step. The | declaration of an atomic step type defines the input ports, | output ports, and options of all steps of that type." | | I think it's worth being pedantic about this at the | beginning, but I'm _not_ going to make comparable suggestions | throughout the rest of the spec. Good, because if you are too agressive on that point, someone's going to suggest that we rename declare-step to declare-step-type and then we'll spend four telcons arguing about it. | 2.2 "In the very simplest case, the declaration is implicit, but" | Hunh? When is a pipeline every not explicitly declared? I | think removing this would be just fine. . . It's implicit in the p:pipeline case where there are no explicit declarations for the source and result ports. But I'm content to remove it as well. | 2.2 Is this the right place to mention that a single output can | be multiply connected? We haven't said it yet (I don't | think), and it would be very easy to start assuming that | there was a one-to-one constraint, in the absence of anything | to the contrary. Something like "An output port may be | connected to more than one input port. At runtime this will | result in distinct copies of the output." just before the | definition of _signature_. Done. | 2.2 "The error output port is only bound to an input in the catch | clause of a try/catch." -> "Error output ports are un-named, | and only accessible via the automatic connection made from | them to the primary input of the *p:catch* subpipeline of an | immediately containing *p:try/p:catch*" Ok. | 2.2 Given that the final discussion in this section about URI | indeterminacy is dealing in double negatives already, is | this the place we should also acknowledge that it's | implementation-defined whether XQuery/XSLT-2.0 rules for | guaranteeing consistency across multiple references to the | same URI are provided or not? I added a para just before the note. | 2.4 A _bit_ more is needed here, or 2.8 is at best difficult to | read and at worst incomprehensible. A para. about the | difference between option declaration and option binding, | with one example each of select= and value=, perhaps. . . I'm not sure what section you're actually referring to here...and I'm afraid I screwed up and checked in the 'alternate' draft on top of the old one. My bad. | 2.7 "[Definition: The readable ports are the step name/port name | pairs that are on steps in the same scope.]" This is too | narrow, there are other readable ports, as set out just | below. I think it's sufficient to just say "[Definition: The | readable ports are a set of step name/port name pairs.]" Ok. | 2.7 See my earlier message for what amounts to a suggestion for | changes to this section. Uhm. I replied to the earlier message so I guess I've addressed these. | 2.8.1 and 2.8.2 "Current dateTime | | An implementation defined point in time." | --> | "Current dateTime | | An _implementation defined_ point in time." Ok. | 2.8.3 "The XProc processor must support" --> "The XProc processor | *must* support" Got it. Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> | Where it is permissible both to die and http://nwalsh.com/ | not to die, it is an abuse of valour to | die.-- Mencius
Received on Tuesday, 18 March 2008 19:07:24 UTC