- From: <Toman_Vojtech@emc.com>
- Date: Thu, 20 Dec 2007 10:59:44 -0500
- To: <public-xml-processing-model-comments@w3.org>
Hi all, I have a couple of questions and comments related to the latest WD: 1. Is there any use for the "name" attribute on p:pipeline-library? If so, what can it be used for? 2. How should an XProc processor behave if it encounters a pipeline library without the "namespace" attribute and the library contains pipelines (or steps) with name but no type information? Does empty (or unspecified) "namespace" attribute mean that all untyped declaration will be in no namespace? Or the XProc namespace? Or, if the "namespace" attribute is used, can it be empty at all? Section 5.8 says that a step declaration cannot be in XProc namespace unless it is a standard step. I guess that it should not be possible to put pipelines in the XProc namespace as well. 3. The spec allows recursive invocations of pipelines. Is the following example valid (only name specified, no type informationprovided)? <p:pipeline name="test"> <test>...</test> </p:pipeline> Or do I have to use the "type" attribute here? <p:pipeline type="test:mypipeline" xmlns:test="http://www.test.com"> <test:mypipeline>...</test:mypipeline> </p:pipeline> I think the spec is not very clear on this topic. 4. Section 4.5 says: "The result of a p:group is the result of its subpipeline." Does this mean the result of the last step in the subpipeline? What if the last step has no primary output? How does this combine with specifying explicit p:output elements on p:group? 5. Section 2.7 says: "If there is a preceding sibling step element: If that preceding sibling has a primary output port, then that output port becomes the default readable port." Shouldn't this be rewritten so that it takes ordering of the steps based on the bindings into account? 6. Section 5.1.1 says: "On p:declare-step, the p:input simply declares the input port. It is a static error (err:XS0042) if the declaration of a document input port inside a p:declare-step. Document input port declarations must be empty unless they are declaring and binding an input port for a p:pipeline."? How does the following text (section 5.1.1) combine with the ability to provide default bindings on p:input? Shouldn't the text be updated? Also, the message for error XS0042 is not really clear. I also think that the following sentence: "Document input port declarations must be empty unless they are declaring and binding an input port for a p:pipeline." should be updated: "Document input port declarations must be empty unless they are declaring and binding an input port for a p:pipeline OR A COMPOUND STEP." 7. I guess the following should not be allowed (providing binding for an output of a standard step): ... <p:identity> <p:output port="result"> <p:empty/> <!-- or any other type of binding --> </p:output> </p:identity> ... 8. Section 5.4: "On compound steps, the declaration may be accompanied by a binding for the output." How is the XProc processor supposed to react if I have a compound step with multiple p:output elements, all without a binding? 9. Input/output ports with sequence="true". If no binding exists for such ports, should they "return" an empty sequence of documents when accessed? 10. For-each steps that get executed zero times. Norman Walsch responded to my (private) e-mail with the following: > | 5.2 What should be on the output ports of a p:for-each if the body is evaluated zero > | times (empty loop sequence)? > > Each should have zero documents on it. Just to be sure: does this apply also to output ports with "static" bindings (e.g. document or inline binding)? 11. Section 5.7.3 (p:namespaces), item 2: "If the element attribute is specified, it must contain an XPath expression which identifies a single element node (the input binding for this expression is the same as the binding for the p:option or p:parameter which contains it). The in-scope namespaces of that node are used; The expression is evaluated in the appropriate context, See Section 2.8, 'XPaths in XProc'." What if the owner option/parameter does not specify any binding? Should the implicit readable port of the owner step be used? 12. Section 5.7.3 (p:namespaces): items 2 and 3 contain MUST - what if the requirements are not satisfied? When an element expression is used, what if it does not evaluate to an element? (fallback to default in-scope namespaces instead of using the element's in-scope namespaces?) 13. Section 5.7.3 (p:namespaces) - what if a sequence of documents appears on the input of the select expression? Should err:XD0008 be reported as in the case of p:option? 14. The text for dynamic error err:XD0014 should be more generic so it is meaningful both for c:parameter and c:parameter-set 15. err:XS0035 mixes two cases together: declaration of parameter inputs cannot contain bindings + the owner pipeline has no primary parameter input port 16. err:XS0043 - is this really a correct error code if a pipe binding is found in an input declaration? 17. Section 5.1.2: When are the "manufactured" bindings for non-primary parameter inputs supposed to be evaluated? Last among the other parameters, similar to the primary parametr input port? I think the text should be relaxed a bit so it covers also non-primary parameter inputs. 18. What if the primary/sequence/... attributes in an input binding do not match the values specified in the input declaration? Do these cases all fall under err:XS0010? 19. Section 5.1.1 (p:input, atomic step): "If no binding is provided, the input will be bound to the default readable port." Does this mean that if I don't specify any bindings for (non-primary) inputs on the step, they all will be bound to the default readable port? (That is, both the primary input port and all the other non-primary input ports will be bound to the same readable port) On an atomic step, is there a difference between specifying an input with no binding (empty p:input element) and not specifying the input at all? Are the two following invocations of the p:xslt step equal? <!-- first --> <p:xslt> <p:input port="stylesheet"/> </p:xslt> <!-- second --> <p:xslt> </p:xslt> I am a bit confused about this. Section 2.2 says that the step matches if it *specifies* all declared inputs, so my understanding is that I really have to specify the inputs (except maybe for the primary inputs which will be "added" automatically by the XProc interpreter), but no bindings are necessary. 20. Section 2.5 says: "Additionally, if a p:pipeline does not declare any parameter input ports, but contains a step which has a primary parameter input port...". I think this sentence should be changed to: "Additionally, if a p:pipeline does not declare any parameter input ports, but contains a step which has a primary parameter input port WITH NO BINDINGS..." 21. xproc.rng: The type OtherAtomicStep can contain only p:input - why not also p:output? Also, what does the declaration of StandardStep look like? -- Vojtech Toman Principal Software Engineer EMC Corporation Aert van Nesstraat 45 3012 CA Rotterdam The Netherlands Toman_Vojtech@emc.com
Received on Thursday, 20 December 2007 15:57:15 UTC