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

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

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Tue, 18 Mar 2008 14:46:26 +0000
To: Norman Walsh <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org
Message-ID: <f5bprtsrsxp.fsf@hildegard.inf.ed.ac.uk>

Hash: SHA1

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

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

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

3.1      associed --> associated 

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

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"

         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.

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

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

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

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

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"

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"

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

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

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

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

- -- 
 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 Tuesday, 18 March 2008 14:47:06 UTC

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