W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > March 2008

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

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Mon, 17 Mar 2008 16:48:00 +0000
To: Norman Walsh <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org
Message-ID: <f5bbq5dwb3z.fsf@hildegard.inf.ed.ac.uk>

Hash: SHA1

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.

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. . .

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_.

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*"

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?

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. . .

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.]"

2.7      See my earlier message for what amounts to a suggestion for
         changes to this section.

2.8.1 and 2.8.2 "Current dateTime

                   An implementation defined point in time."
         "Current dateTime

           An _implementation defined_ point in time."

2.8.3    "The XProc processor must support" --> "The XProc processor
          *must* support"

- -- 
 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]
Version: GnuPG v1.2.6 (GNU/Linux)

Received on Monday, 17 March 2008 16:48:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:45 UTC