Re: Uncle! New alternate draft [remainder of comments on section 2]

/ 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