Re: Another take on versioning

"Toman_Vojtech@emc.com" <Toman_Vojtech@emc.com> writes:
> "1. If an unknown step in the XProc namespace is encountered, it is
> assumed to be correct."
>
> What does "correct" mean in this case? Because the step is unknown, the
> processor has no idea about how its signature (input ports, output
> ports, options, ...) looks like. Knowing the input and output ports (and
> which ones are primary, if any) is essential to determine the correct
> evaluation order of steps in the pipeline.

I managed to convince myself that this wasn't actually a problem. Any
attempt to evaluate an unknown step will raise an error, so unless the
step occurs inside a p:when or the p:group of a p:try, the error can
propogate upwards. In a p:when or p:try, you know the order because
you have the other branches.

But that's an awfully dramatic change and I could be wrong. Certainly,
there may be sharp edges somewhere. So let's back off a bit.

(I know we're late in the game, I desperately want to reject any
change in this area, but I'm acutely aware that if you don't get this
right in V1.0, it's very hard to fix.)

What I think Vasil has identified pretty persuasively is that the
status quo makes it very hard to write conditional pipelines that can
degrade gracefully on older processors.

Perhaps a much less agressive change will cover it though. Ignore my
earlier proposal in this thread.

Instead of saying that "it is a static error if the signature of a
known step in the version library has changed, except for new options",
we say:

  3. It is a dynamic error to attempt to evaluate a step that has unknown
  attributes or unknown descendants.

This makes it statically ok to say:

  <p:identity>
     <p:xyzzy/>
  </p:identity>

but the step will always raise an error if it is evaluated.

  4. If the signature of a step includes unexpected input ports, any
  inputs that appear on those ports will simpy be ignored.

This means that if p:identity grows a new input port, it'll be ok for a 1.0
processor to process that step, it will simply do whatever it does without
paying any attention to the new inputs.

  5. If the signature of a step includes unexpected output ports, an
  empty sequence of documents will appear on that port. (Consequently,
  it will be a dynamic error if the new ports do not accept a sequence
  of documents.)

This means that if p:xslt grows a new output port, it'll simply always
produce an empty sequence of documents if it's used by a 1.0
processor.

  6. New options on known steps are ignored.

Same as before.

I think this all works because we will continue to require that a 1.0
processor has all the declarations for the 2.0 steps.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If God created us in his own image, we
http://nwalsh.com/            | have more than reciprocated.-- Voltaire