Re: Requirements Document Update

At 10:19 PM 1/25/2006 -0800, Alex Milowski wrote:
>Murray Maloney wrote:
>>Many of my previous comments still pertain. We can discuss later.
>Please do elaborate! :)

Links to current and previous versions do not work.

I think that Design Principles should be presented in this order:

         Technology Neutral -- terms have not been defined
         Small and Simple
         Straightforward Core Implementation
         Address Practical Interoperability -- explain this more fully
         Infoset Processing -- terms have not been defined
         Arbitrary Components -- terms have not been defined

Perhaps Definition of terms should precede design principles.

In the list of requirements, I would prefer to see like things grouped.
Further, I would prefer to see logical progression within groups.
Finally, I would like prefer to see req's supported by design principles
precede other req's.

4.1 I think that I might understand the requirement, but I would use the
expression "provide mechanisms to control" rather than "allow control".
The requirement "must allow" is generally satisfied by granting permission.
Granting permission is necessary but not sufficient.

The first sentence is clear to me. I don't understand the following:

At minimum, the characteristics of these inputs and outputs must be 
described so that binding into particular use environments can be 
accomplished by introspection. This may involve the use of named infoset 
inputs and outputs.

4.3 s/mechanism/mechanisms/ or s/mechanism/a mechanism/

4.4  I would re-phrase these as:
The model and specification language must provide mechanisms for
ordering processing steps over a set of inputs and components.

4.5 Neither the model nor the language should inhibit
a sophisticated implementation from performing parallel operations, lazy
or greedy processing, and other optimizations.

4.6 I don't understand:
There should be some support for analysis of an XML pipeline to detect this 
ability.

But the wording should be something like:
The model and specification language must provide mechanisms for ...

4.7 Neither the model nor the language should inhibit applications from
defining new process steps that use new components.

I am not sure that I understand what the following sentence means:
Such definitions should be easily used and shared amongst instances
XML Pipeline in the Specification Language.

Please clarify.

4.9 Minor edits:
XML Pipelines and the Specification Language should provide mechanisms for 
conditional processing of documents, or elements within documents, based on 
expression evaluation, to allow run-time selection of steps.

4.11 The model and specification language must provide mechanisms for
using the following components:
         ...
This item should precede what is now 4.7

4.11 The two paragraphs seem redundant.

4.12 XML Req should be stated much earlier. It is fundamental and is supported
by a design principle.

4.13 Seems to be redundant with 4.11
4.14 Seems to be redundant with 4.11

4.15 The model and specification language must provide mechanisms for
dependency-based or sequence-based pipeline composition.

4.16 The model and specification language must provide mechanisms for
explicitly naming pipelines and using those pipelines by reference.

4.17 Although not redundant with 4.11, should be grouped with.

4.18 Begs question. What are "standard" names?

4.19 The model and specification language must provide mechanisms for
iteration of steps over collections of documents and over elements within a 
document.
This iteration should allow application of specific steps to the target of 
the iteration.