Re: Uncle! New alternate draft [first set of comments]

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| SotD: Needs to be brought up to date. . .
|
| 1, just after Figure 1: "list of W3C XML Schemas" -> "sequence of W3C
|                         XML Schema documents"

Fixed.

| Example 2  Why not use p:pipeline and get rid of the source and result
| 	   ports?

Ok.

|
| Example 3  Leave step names out?  They're not doing anything . . . You
|            switch to p:pipeline here, w/o any explanation: I
|            definitely now think the switch should come earlier, with
|            something like "For pipelines with one input and one
|            output, p:pipeline can be used instead of p:declare-step,
|            and input and output declarations are provided by default."

Yes.

| 2.         (last para before 2.1) Maybe add something along the lines
|            of "The pattern of connections between steps will not
|            always completely determine their order of evaluation: the
|            evaluation order of steps not connected to one another is
|            _implementation-dependent_."

Ok.

| 2.1        [Climbs back on old hobby-horse] The pseudo-production for
| 	   subpipeline contains 'pfx:other-step', which links to a
| 	   section labelled 'pfx:other-atomic-step'.  Shouldn't the
| 	   production have 'p:standard-step|pfx:user-pipeline, and both
| 	   link tableaux at the top of 4.7, which should be called
| 	   *Atomic Steps*, and should begin "Other steps are specified
| 	   by elements that occur as _contained steps_, invoking either
| 	   standard (built-in) steps or user-defined pipelines:"
| 	   followed by two tableaux, one for pfx:user-pipeline and one
| 	   for p:standard-step, each otherwise the same as the existing
| 	   pfx:other-atomic-step.  (Other comments about 4.7 below)

I'll meet you half way :-) I tinkered with the links in subpipeline,
renamed 4.7, and tinkered with the prose and the tableux, but didn't
duplicate the tableux.

| 2.1        After the para after the pseudo-production, how about "On
|            the other hand, p:user-pipelines are treated as
|            atomic---although a pipeline _definition contains a
|            subpipeline, a step which invokes a user-defined pipeline
|            does not."

I did something like that. The para immediately after the
pseudo-production actually no longer makes any sense given the
adoption of multi-container step terminology.

| 2.1.1      I'm still not happy with when/choose/catch having names.
|            This would appear to allow me to write e.g.
|
|            <p:choose>
|             <p:when name="never" test="1=0">
|              <p:output name="result"/>
|              ...
|             </p:when>
|             <p:when>
|              <p:xpath-context>
|               <p:pipe step="never" port="result"/>
|              </p:xpath-context>
|             . . .
|
|            </p:choose>
|
|           but that's clearly incoherent.  The situation wrt how the
|           containers/pseudo-steps interact with the environment rules
|           needs to be clarified.  I think we can't maintain the
|           current attempt to shoehorn them into a strict
|           step/step-container duality.

Ok. I'm willing to float the idea that only steps (atomic, compound,
or multi-container) have names.

Then we get to p:group and I start to think that maybe we should just
say to heck with it and have p:trycatch/p:try/p:catch.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Men are more like the times they live
http://nwalsh.com/            | in than they are like their
                              | fathers.--Ali Ibn-abi-talib