[closed] Re: Remarks on W3C Editor's Draft 24 January 2008 ( part II)

/ Innovimax SARL <innovimax@gmail.com> was heard to say:
| Dear,
|
| The Abstract says
| [[
|
| An XML Pipeline specifies a sequence of operations to be performed on **one
| or more** XML documents. Pipelines generally accept **one or more** XML
| documents as input and produce **one or more** XML documents as output.
| Pipelines are made up of simple steps which perform atomic operations on XML
| documents and constructs similar to conditionals, **loops** and exception
| handlers which control which steps are executed.
| ]]
| emphasis is mine
|
| But later in 1 Introduction we find
|
| [[
| An XML Pipeline specifies a sequence of operations to be performed on a
| collection of XML input documents. Pipelines take **zero or more** XML
| documents as their input and produce **zero or more** XML documents as their
| output.
| ]]
|
| Please do hamonize them
|
| Furthermore, I dislike the word "loops" in the abstract. Later in the spec
| it is referenced as "iterations" which is more appropriate.

Fixed.

| [[
| The inputs to a step come from the web, from the pipeline document, from the
| inputs to the pipeline itself, or from the outputs of other steps in the
| pipeline. The outputs from a step are consumed by other steps, are outputs
| of the pipeline as a whole, or are discarded.
| ]]
| isn't it more "inputs of" instead of "inputs to" ?

*Shrug* Ok.

| To be consistent with the Figure 1, please replace "Validate" by "Validate
| with XML Schema" in the text after the figure.

Fixed.

| In 2.1 Steps
|
| [[
| [Definition: A step is the basic computational unit of a pipeline.] A
| typical step has some number of inputs, from which it receives XML documents
| to process, some number of outputs, to which it sends XML document results,
| and may have options and/or parameters.
| ]]
|
| Please replace "some number of" by a more precise "zero or more"
| isn't the "may" in "may have" an RFC one ?

Fixed. No, I don't think so, so I changed it to 'can'.

| s/a Validate with XML Schema step validates/a Validate-with-xml-schema step
| validates/

I dunno. I think I prefer "Validate with XML Schema" or
"p:validate-with-xml-schema". And in this context, I'd rather not
refer to the element.

| For "implementations may provide others as well", RFC may
| (After reading a bit more of the spec, I think a lot more may and must
| should RFC'ied, but I fear I have no idea of what the rule of thumbs are...)

Bleh. I think the only sane rule of thumb is that all occurrences of
"may", "should", and "must" MUST :-) be RFC 2119 or the sentence should be
rewritten to use different words.

| After
| [[
|  It is not an error to connect a port that is declared to produce a sequence
| of documents to a port that is declared to accept only a single document. It
| is, however, an error if the former step actually produces more than one
| document at run time.
|  ]]
| Please add that the reverse is also not an error, say
| [[
|  It is not an error to connect a port that is declared to produce a single
| document to a port that is declared to accept only a sequence of documents.
| The sequence of one document and a single document are considered the same.
| ]]

Fixed.

| [[
| A step matches its signature if and only if it specifies an input for each
| declared input,
| ]]
| I don't think this is true, since we can omit non primary inputs

I think unspecified primary input and output ports are implicitly
"specified" for the purpose of matching.

On the other hand, if you have a specific wording suggestion...

| s/URIs.Whether/URIs. Whether/

Fixed.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The facts, although interesting, are
http://nwalsh.com/            | usually irrelevant.