Re: Uncle! New alternate draft [more comments through the end of section 4]

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 2.4      This is a _huge_ and complex section and completely derails
|          the momentum of a reader who still hasn't gotten to the basic
|          pipeline syntax.  I think it worked better down in section 5
|          where it used to be. . .

Well. Ok. I'll try that. I didn't like the way it came out when I was
using the machete, but maybe I can reformulate it a bit.

| 3        The Note at the beginning of this section is quite bizarre --
|          what is it trying to tell us?  Do we really need it?

I don't think so.

| 3.1      associed --> associated

Fixed.

| 3.2      Maybe useful to add here something like "Step types,
|          variables, options and parameters are named with QNames;
|          steps and ports are named with NCNames".

Done.

| 3.7      "any other conformant XProc processor would produce" -->
|          "would arise in the absence of the attribute"; "a conformant
|          processor is required to signal" --> "would be signalled in
|          the absence of the attribute"

Much better, thank you.

|          The final sentence is confusing at best and should probably
|          be removed: being implementation-{defined,dependent} doesn't
|          _ipso facto_ keep you from sinning in one of the two ways
|          specified above.

Ok.

| 4.1      "e.g., ones that are provided" --> "e.g. ones that contain an
|          explicit subpipeline, or are provided"

Ok.

| 4.1      No p:variable allowed?  Ah, I see -- no p:variable allowed
|          _anywhere_ :-).  I take it the syntax hasn't been updated
|          yet. . .

p:variable is allowed in subpipeline. And now at the beginning of p:choose
and p:try.

|          I would vote for allowing p:variable in the prologue of any
|          container, meta-container, p:pipeline or p:declare-step.

I don't think we want to allow variables to be mixed in with the other
prologue elements. 

In particular, if we allowed a variable to occur before a parameter,
we'd have to restrict the variable in ways that we don't if we just
let it come after.

| 4.1      I think the duplication between this and p:declare-step is
|          unnecessary.  I would suggest removing
|          * The third paragraph
|          * Everything after the first para. after the tableau down
|            through para which begins "If a step within the
|            _subpipeline_ needs".

Works for me!

| 4.2      "If the iteration source for a p:for-each is an empty
|          sequence, then" --> "If the iteration source for a p:for-each
|          is an empty sequence, then the subpipeline is never run and"

Fixed.

| 4.2      "If the p:for-each has a primary output port and . . ." --
|          it's not clear from this whether the defaulting rule from the
|          end of section 2.3 applies before this clause, as it were.
|          Surely it is meant to, so I would suggest --> "If the
|          p:for-each has a primary output port (explicit or supplied by
|          default (see [ref. 2.3]) and"

Yep.

| 4.3      "The p:viewport must contain a single, primary output port."
|          Why is p:viewport different from p:for-each in this regard?
|          Or rather, it's easy to read this as implying that every
|          p:viewport must contain an _explicit_ p:output.  Again, I
|          presume that's not what's meant, so suggest --> "The
|          p:viewport must have a single, primary output port, either
|          declared explicitly or supplied by default (see [ref. 2.3])."

Ok.

| 4.4.2    "effective boolean value is the guard expression" -->
|          "effective boolean value is the guard"

Ok.

| 4.6      (minor niggle): s/result/output/ throughout, perhaps?
|          Compare 4.4 (which does have _one_ 'result', I admit :-(

Sure and not anymore, respectively. :-)

| 4.7      We've given ourselves an upgrade path for adding new
|          built-in/standard atomic steps, but we haven't done so for
|          new compound steps.  I'm not happy with my earlier
|          'hobby-horse' comment on the 'subpipeline' pseudo-production
|          in section 2.1, either.  I guess I'll send a separate message
|          about this whole mess. . .

Yes, please. I recall that you argued for *removing* the bits of the
spec that attempted to be more open about compound steps. But maybe
that's because they weren't very clear.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It is seldom that any liberty is lost
http://nwalsh.com/            | all at once.--David Hume