W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > January 2008

RE: declare-step - atomic steps vs. empty pipelines

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>
Message-ID: <478ca6f9.0637560a.280f.ffffd3d7@mx.google.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 15 January 2008 16:31:21 GMT