RE: Another take on versioning

> On 9 Oct 2009, at 21:44, Jeni Tennison wrote:
> > 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 Norm summarized the problems with this very nicely in his
previous email. And it is not just that the processor will often make
wrong assumptions about the steps - there are also a number of error
conditions related to unconnected output ports etc. What can happen is
that a pipeline that is statically incorrect in V2 (because, for
instance, of unconnected output ports) may be accepted in V1 processor
(because the processor makes some incorrect assumptions about the V2
steps).

> Put another way, what I'm suggesting is:
> 
> "Forwards-compatible mode is triggered in libraries/pipelines 
> in which  
> the XProc version is greater than the version recognised by the  
> processor. In forwards-compatible mode:
> 
>    * Unrecognised attributes on elements in the XProc namespace are  
> ignored.
> 
>    * Unrecognised steps in the XProc namespace are marked as invalid.
> 
>    * Unrecognised options on XProc steps are ignored.
> 
>    * If an XProc step contains inputs that are not part of its  
> signature, those inputs are ignored.
> 
>    * If a step contains an input that contains a <p:pipe> that  
> connects to an unrecognised output on an XProc step (which would  
> normally cause err:XS0022), these inputs are replaced by:
> 
>      <p:input port="...">
>        <p:empty />
>      </p:input>


But the dependency between the two steps must still be preserved. Simply
replacing the p:pipe binding would break the dependency graph.

I hink the latest draft deals with this case correctly: it keeps the
connection/dependency between the steps, but if a step attempts to read
from an unknown output port, it gets an empty sequence.  

All in all, I think your proposal does not differ that much from the
latest draft. The only significant difference is the p:import
requirement :)

Regards,
Vojtech

--
Vojtech Toman
Principal Software Engineer
EMC Corporation
toman_vojtech@emc.com
http://developer.emc.com/xmltech

Received on Monday, 12 October 2009 07:49:03 UTC