Re: Comments on August 10 editors' draft through section 2.6

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| Abstract:
|
|  producing --> produce

Fixed.

|  I think this sentence is too obscure for where it occurs:
|
|    "Some pipelines are entirely self-contained, starting with input
|     derived inside the pipeline and producing no XML output."
|
|  and the ", though they are not required to do so." ending to the
|  previous sentence is unnecessary, given the "generally" at the
|  beginning.
|
|  How about just
|
|    Pipelines generally accept one or more XML documents as input and
|    produce one or more XML documents as output.  Pipelines are made up
|    of simple steps which perform atomic operations on XML documents
|    and constructs similar to conditionals, loops and exception
|    handlers which control which steps are executed.

Fine by me.

| and if you _really_ think we need to say something more, add
|
|    Input and output of some kinds of non-XML documents is possible via
|    special-purpose steps.
|
| SoTD:
|
|  We can't go to Last Call with this sentence in place:
|
|   "This draft addresses many, but not all, of the design questions that
|    were incomplete in previous drafts."

Yeah. I ignore the SoTD. Doesn't everyone?

| Introduction:
|
|    "whereas compound steps include a subpipeline of steps within
|     themselves."
|     -->
|    "whereas compound steps control the execution of other steps,
|     which they include in the form of one or more subpipelines."

Ok.

| 2 Pipeline Concepts:
|
|    "Unless otherwise indicated, implementations must not assume that
|     steps are functional . . ."
|
|  I can't find anywhere where we give a functionality guarantee -- can
|  we just remove the "Unless otherwise indicated, "?

I think the idea was to leave the door open for implementations to
provide extension attributes to do this.

| 2.1 Steps:
|
|  Should we make
|
|   "The steps that occur directly inside a compound step are called
|    contained steps."
|
|  more accurate, e.g. by saying
|
|   "The steps that occur as children or, in the case of *p:choose* and
|    *p:try*, as grandchildren, of a compound step are called contained
|    steps."

Bleh. I'm not sure what to do about that.

|  I'm not clear why we call out implementation-defined compound steps
|  (pfx:other-step in the production for 'subpipeline').  Where do we

pfx:other-step in the production for subpipeline stands for both atomic
and compound steps.

|  define the behaviour of a processor when it sees one such?  How does
|  a processor tell the difference between a pfx:other-step and a
|  ipfx:ignored?  The way I read 3.6 only ipfx:ignored should be in that
|  production.

What? You don't want to be able to put a p:delete in a subpipeline? Or a
ex:some-pipeline-I-want-to-call?

| I think we should get rid of the 'compound' part of 4.7
|  altogether, and simply observe that extensions may be simple or
|  compound, and will have implementation-defined syntax and semantics.
|
|  After all, the 'simple' part of 4.7 isn't about extensions at all,
|  it's about user-defined step types, which are distinct from
|  extensions.

I'm not sure.

|  When/why did we decide that a step can't have both an input and an
|  output port with the same name?  What bug does this forestall?

So long ago that the decision is lost in the mists of time.

It gaurantees that the statement "The 'x' port on step 'y'" is
unambiguous. What benefit would there be in allowing two ports with
the same name?

| 2.1.1 Step names:
[...]

I'm not mentally up to the task of trying to untangle this now. I'll come
back to it in a bit.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Knowledge, sense, honesty, learning,
http://nwalsh.com/            | good behavior are the chief things
                              | towards making a man's fortune, next to
                              | interest and opportunity.