- From: Vasil Rangelov <boen.robot@gmail.com>
- Date: Tue, 15 Jan 2008 12:28:53 +0000
- To: <public-xml-processing-model-comments-request@w3.org>
You may be right on this one... the spec is actually very vague in this regard. Exactly how can ISEAS(Internally Supported Extension Atomic Step)s be used, and how are they resolved against these same steps when definitions are present? I see no definite clarification in the spec. To my understanding, ISEASs should be accessible directly, with no declaration, and in cases where an implementation doesn't support an extension step internally, it may throw an error if the step is used even though it's not available, or if it's available from a declaration, but no pipeline was evaluated*. When a declaration of an ISEAS type is present within a pipeline or a library, the processor must take the ISEAS implementation with a priority over the declared one. Ideally, there should be some new attribute on p:declare-step that would resolve such conflicts. Something like a force-usage attribute maybe, that would specify whether or not a pipeline in p:declare-step would take precedence over any ISEAS' implementation. I can imagine use cases for both scenarios. When EXProc.org comes out, it will be great if implementations in XProc could be provided for processors that don't have that ISEAS, but processors that do have a certain ISEAS would use their implementation. At the same time, it will be great if you can somehow ensure that your implementation will be used no matter what. Perhaps resolving the conflicts with ISEASs was part of the reason of the creation of p:pipeinfo (which for now looks just like p:documentation, but gathering from the XProc minutes, it will become more than that). *The latter case may be avoid if dynamic creation of steps was allowed and empty pipelines forbidden i.e. be able to do something like: <p:choose><p:when test="p:step-available('test:my-atomic-step')"> <p:declare-step type="test:my-atomic-step"> <p:input port="source"/> <p:output port="result"/> <!--test:my-atomic-step implementation in XProc--> </p:declare-step> </p:when></p:choose> But I suppose this would provide implementation difficulties, so it's probably out of the question for V1. -----Original Message----- From: public-xml-processing-model-comments-request@w3.org [mailto:public-xml-processing-model-comments-request@w3.org] On Behalf Of Toman_Vojtech@emc.com Sent: Monday, January 14, 2008 2:48 PM To: public-xml-processing-model-comments@w3.org > You don't need to declare or import extension steps for which the pipeline processor has internal support. Is it really so? Section 4.7 says that: "Each atomic step must be the name of a p:pipeline type or must have been declared with a p:declare-step that appears in the pipeline, or an imported library, before it is used." This has always been my understanding of declaring steps in XProc. Whether or not the pipeline processor supports an (extension) atomic step, it must be declared before it is used. > That will only be evaluated if the pipeline processor doesn't have internal support for test:my-atomic-step already. Is this in the specification? But I still think that even if the processor knows how to evalate the step, it needs to access the declaration to check whether the step matches its declared signature. Vojtech -----Original Message----- From: public-xml-processing-model-comments-request@w3.org [mailto:public-xml-processing-model-comments-request@w3.org] On Behalf Of Vasil Rangelov Sent: Monday, January 14, 2008 12:54 PM To: public-xml-processing-model-comments@w3.org I thought that steps and pipelines were unified thanks to this syntax. You should be able to have <p:declare-step type="test:my-atomic-step"> That will only be evaluated if the pipeline processor doesn't have internal support for test:my-atomic-step already. In this essence, an empty pipeline, and an empty step declaration are the same thing. You don't need to declare or import extension steps for which the pipeline processor has internal support. -----Original Message----- From: public-xml-processing-model-comments-request@w3.org [mailto:public-xml-processing-model-comments-request@w3.org] On Behalf Of Toman_Vojtech@emc.com Sent: Monday, January 14, 2008 11:55 AM To: public-xml-processing-model-comments@w3.org Hi all, I have a question about the "new" p:declare-step syntax with regard to declaring empty pipelines. It seems to me that in some cases the XProc processor has no way of knowing whether the declared step is an atomic step or an empty pipeline. Consider this library: <p:library xmlns:p="http://www.w3.org/ns/xproc" xmlns:test="http://acme.com/test"> <p:declare-step type="test:my-atomic-step"> <p:input port="source"/> <p:output port="result"/> </p:declare-step> <p:declare-step type="test:my-empty-pipeline"> <p:input port="source"/> <p:output port="result"/> <!-- empty subpipeline --> </p:declare-step> </p:library> Suppose the implementation for the step "test:my-atomic-step" is not available to the processor. In that case, the processor should report an error on this step (XD0017, attempt to invoke a step which the processor does not know how to perform). But for the "test:my-empty-pipeline" step, the situation is different, because it is meant to represent an empty pipeline - so it should be processed with no problems. The problem is, however, that the two step declarations look exatcly the same to the processor... I can think of two solutions to this: 1. Disallow empty pipelines 2. Enhance the p:declare-step element so it is always clear whether it declares an atomic step or a pipeline Regards, Vojtech
Received on Tuesday, 15 January 2008 16:31:20 UTC