Re: "Feature complete" XProc draft

Hi Norm,

> I believe that the editor's draft at
> 
>   http://www.w3.org/XML/XProc/docs/ED-xproc-20060821/
> 
> is feature complete.

Regarding feature completeness: there doesn't seem to be anything in the 
spec on extension elements/attributes, nor on documentation, both of 
which I think we had at least preliminary decisions about. We did also 
tackle a couple of the standard components, and came up with a massive 
list of other possibles which it might be worth capturing in the draft 
(especially if you can arrange them into groups).

A few editorial (I think) comments, on reading it through again:

1. I think you should mention "error outputs" in the definition of 
components (2.1) or inputs and outputs (2.2). Currently, the concept is 
only introduced when you talk about try/catch constructs (3.5).

2. It's not clear to me whether "Other Components" (3.6) is about 
implementation-defined components (that you would refer to using 
p:step/@component) or implementation-defined language constructs (that 
would have their own specialist element, on a par with for-each/choose 
and the other components listed in "Language Constructs" (Section 3). If 
the former, I don't think this text belongs in Section 3; if the latter, 
I don't think implementations should have to define a signature for 
language constructs (just as you haven't for for-each/choose etc.). As 
we've discussed, language constructs are special, and don't have 
signatures like other components. (In fact, I wonder if we should avoid 
calling them "components" altogether.)

3. I would like to see the 'select' attribute covered in Section 4.1.1 
(Associating Documents with Ports), since that's what it does. I don't 
see any reason why <p:declare-output> shouldn't have a select attribute.

4. In Section 4.2.1 (p:pipeline Element), Section 4.2.4 (p:step Element) 
and elsewhere, we will have to make clear how QNames in attribute values 
are resolved: without a prefix, does it use the default namespace or no 
namespace? If pipeline names must have a namespace (which I think is 
probably a good idea) then I think QNames without a prefix should belong 
to the default namespace.

5. If we're using "p:declare-parameter" and "p:parameter" then I think 
we should use "p:import-parameter" rather than "p:import-param". (Maybe 
it should be plural, in fact, since you can import more than one at a time.)

6. Near the end of 4.2.5 (p:input Element), you talk about the role of 
the 'select' attribute. Since this is an XPath expression rather than an 
XSLT pattern, I think you should be talking about *selected* nodes 
rather than *matched* nodes.

7. In Section 4.2.6 (p:param Element), I believe that we wanted to allow 
a 'value' attribute as well (with perhaps a note saying that only one or 
two of the possibilities was likely to survive to future drafts). Also, 
earlier on this was called the p:parameter element...

8. In Section 4.2.7 (p:import-param Element), the syntax specification 
gives the value of the name attribute as 'tokens', which implies that 
this would be a list of tokens. If it's just a single token (as 
specified by the text) then the syntax spec should say 'token'.

9. In Section 4.2.8 (p:for-each Element), the explanation of the example 
says: "The resulting HTML and FO documents are aggregated together and 
appear on the html and fo ports, respectively, of the chapters step." I 
think it would be clearer if it said "The resulting HTML documents are 
aggregated together and appear on the html port of the chapters step, 
and the resulting FO documents are aggregated together and appear on the 
fo port of the chapters step." At the moment, it sounds a bit like the 
HTML and FO documents are all aggregated together into one sequence.

10. In Section 4.2.10 (p:choose/p:when/p:otherwise Elements), I may have 
misinterpreted but was under the impression that these elements could 
have 'href' (and 'select') attributes.

11. On p:group (Section 4.2.11) and in fact on the other language 
constructs, I'm pretty sure that we wanted to allow arbitrary 
p:declare-input and p:declare-param in order to support scoped 
references to documents and parameters. This was our way of supporting 
variables without having variables.

12. In Section 4.2.12 (p:try/p:catch Elements), why not just call the 
input port "!error"? I don't think we need a # as in "!#error". We can 
just mandate that there is an implicit input port declaration called 
"error".

13. Section 4.2.13 (p:declare-component Element), the last paragraph says:

   "The input and parameter declarations of a p:declare-component may use
    the name “*” to indicate that the component accepts an arbitrary
    number of inputs, outputs, or parameters."

Is "*" allowed on output declarations too? If it is, then the paragraph 
should say:

   "The input, output, and parameter declarations of a
    p:declare-component may use the name “*” to indicate that the
    component accepts or provides an arbitrary number of inputs, outputs,
    or parameters."

If not, then it should say:

   "The input and parameter declarations of a p:declare-component may use
    the name “*” to indicate that the component accepts an arbitrary
    number of inputs or parameters."

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 23 August 2006 09:04:05 UTC