RE: Extension steps and declarations

> Consider the following pipeline:
> 
> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
> 	    xmlns:cx="http://xmlcalabash.com/ns/extensions">
>   <cx:message message="I just did the identity step!"/>
> </p:pipeline>
> 
> Can *any* conformant processor run that pipeline?
> 
> One position says, that's a Calabash extension step, Calabash knows
> how to run it, so the answer is clearly "Yes".
> 
> Another position says, what about:
> 
>    Extension steps [...] and there must be a visible step declaration
>    at the point of use (see Section 3.2, "Scoping of Names").
> 
> There's no visible declaration, so the answer is clearly "No".

I remember discussing this before. If the pipeline imported a
Calabash-specific library that declares cx:message, then any compliant
processor should be able to run it, I think.

If the processor does some magic and "automiports" a number of
libraries/steps for the user, so that they are always available, then
there is a possible interoperability problem.

I would say that if you want to write pipelines that are really
interoperable, you must always explicitly import all libraries you are
using.

> 
> Except we're talking about an *extension* step, right? So there's no
> interoperability virtue in making the declaration visible. The
> declaration won't help another implementation run it.
> 

It will. At least there will be a visible step declaration, so the
processor can attempt to execute the pipeline.

> Well, ok, continuing down this slippery slope. Suppose I have this
> perfectly ordinary pipeline library on my system:
> 
> <p:library xmlns:p="http://www.w3.org/ns/xproc">
>   <p:pipeline xmlns:ex="http://example.com/steps/foo"
>               type="ex:foo">
>     <p:identity/>
>   </p:pipeline>
> </p:library>
> 
> Can *any* conformant processor run this pipeline?
> 
> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
> 	    xmlns:ex="http://example.com/steps/foo"
>   <ex:foo/>
> </p:pipeline>
> 
> Now you might be tempted to say, "No, of course not" because that
> step isn't an extension step, so how could you know what it is?

If you import it, it will run. Actually, the distinction between
"normal" steps/pipelines and "extension" steps doesn't seem that clear
to me anymore. Anything you import becomes an extension step, in a
sense. It is in some namespace, it has a declaration. Only in some cases
(unsupported extension - real extension - steps) the processor may not
know the implementation.

> 
> But, suppose my implementation has a configuration file or a command
> line option that lists libraries that should be loaded by default. So
> what if the perfectly ordinary library you identified has already been
> loaded by my implementation, can I run it then?
> 
> I think:
> 
> 1. If we agree that Calabash should be able to run the first example,
>    then the consistent position is to say that it should also be able
>    to run the second example if it's imported the library through some
>    out-of-band mechanism.
> 
> 2. If we agree that processors can load arbitrary libraries through
>    out of band mechanisms and that those mechanisms are sufficient to
>    satisfy the "visible step declaration" clause, then we've blown
>    interoperability out of the water.
> 
> So I propose that *both* pipelines are invalid. If I want to run a
> Calabash extension, I should have to explicitly declare or import the
> declaration in the pipeline:
> 
> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
> 	    xmlns:cx="http://xmlcalabash.com/ns/extensions">
>   <p:import href="http://xmlcalabash.com/extensions/builtin"/>
>   <cx:message message="I just did the identity step!"/>
> </p:pipeline>

I agree. We have already implemented support for option 2 in our
processor, but I have no problems with removing it - or at least
documenting it as a feature with possible interoperability problems.

Regards,
Vojtech

Received on Friday, 21 November 2008 12:59:21 UTC