- From: Murray Maloney <murray@muzmo.com>
- Date: Thu, 26 Jan 2006 10:00:50 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-Id: <5.1.1.6.2.20060126092013.05670128@mail.muzmo.com>
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.
Received on Thursday, 26 January 2006 15:00:34 UTC