Re: Another take on versioning

Hi,

Looking at the forwards-compatible versioning story in http://www.w3.org/XML/XProc/docs/alternate/ 
  ...

My basic standpoint is that users should be able to take a v2.0  
pipeline and run it in a v1.0 pipeline engine without doing anything  
special, so long as either the pipeline doesn't use any new  
(unrecognised) steps or those steps are wrapped in an appropriate  
<p:choose>. Of course they can't expect that it would then work  
exactly as the v2.0 pipeline, and they will suffer if the pipeline  
contains certain errors because they might not be picked up, but  
that's their lookout.

I feel extremely uncomfortable about the use of a <p:import> to  
identify the version of XProc that is being used in a given pipeline,  
especially as it is not clear to me from the spec what would happen if  
I imported a module that imported a different version of the XProc  
steps than the one I've imported. The fact that the spec describes the  
syntax of the URIs for those steps (!!) implies to me that they are  
special and therefore should be treated differently from other steps.  
I would much prefer the use of a lexically-scoped version attribute  
(allowed only on <p:pipeline> and <p:library> I think) to a <p:import>.

As I understand it, the reason for requiring the <p:import> is to  
enable processors to work out the signature of steps that they don't  
know about, so that they can connect up the steps correctly. So here's  
my dumb question: the only outputs that you need to care about are the  
ones that are connected, so couldn't a processor work out what outputs  
a step is supposed to have based on the connections to those outputs?  
And couldn't it just assume an empty sequence on those ports without  
needing to know the declaration?

I think what I'm saying boils down to, in forwards-compatible mode,  
making it not an error to have a <p:pipe> from an unknown port on a  
step in the XProc namespace. This is similar to:

   "5. If a step declares additional outputs, they are treated normally
       for the purpose of computing the dependencies in the pipeline.  
Such
       steps are not invalid; in forwards-compatible mode, an empty  
sequence
       of documents will appear on each additional output."

but doesn't require the processor to know the signature of the revised  
step. Perhaps that's just impossible, but I think it would make life  
easier for the authors of these pipelines.

Of course not knowing about the new step declarations does mean that  
the 1.0 processor wouldn't know about any extra options or inputs that  
they specify, nor about any other child elements they might have. But  
I don't think that's a problem if you say that in forwards-compatible  
mode:

   * any connections (on XProc steps) to unknown inputs must be ignored
   * any unknown options (on XProc steps) must be ignored

which is basically what it says now.

The other thing which bothers me is the prohibition on the use of  
steps whose declaration includes an unrecognised element. The biggest  
problem being that there's no way to guard against it except by not  
using the step at all; this is a massive problem if the step is a  
vital one like p:xslt!

Wouldn't it be easier (on the user) if the unrecognised element was  
just ignored? It means that extra elements allowed within <p:declare- 
step> won't be able to substantially change the way that steps work  
(eg by implicitly declaring inputs or outputs) but I really can't see  
that as a big problem.

Well, you asked for comments...

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 9 October 2009 20:45:25 UTC