- 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
-----BEGIN PGP SIGNED MESSAGE-----
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. . .
ht
- --
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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFH39XCkjnJixAXWBoRAu5+AJ9TKEDtFapYxyRrGEsvBFcj05E1IwCdEBN9
pMUx8A6ztJYFdrISAbr0hts=
=i0Po
-----END PGP SIGNATURE-----
Received on Tuesday, 18 March 2008 14:47:06 UTC