Re: Another take on versioning

"Henry S. Thompson" <ht@inf.ed.ac.uk> writes:
> Norman Walsh writes:
>
>> 1. We replace the existing p:import mechanism with a version attribute.
>>    If the version requested > version of processor, then run in forwards
>>    compatible mode.
>
> We don't replace p:import, we just get rid of the requirement to
> import pipeline libraries for new versions, right?

Right. We'll probably have to say something about the relationship
between the version number and the importing of standard steps, but I
don't know what.

>> 2. While loading/analyzing a pipeline
>
> in forwards-compatible mode only, right?  Otherwise the following are
> all static errors, right?

Yes.

>>    a. Discard unrecognized attributes on elements in the XProc namespace
>>    b. Discard unrecognized elements in the XProc namespace
>>    c. Discard unrecognized options on XProc steps
>>    d. Discard unrecognized ports on XProc steps
>>    e. Turn any reference to an unrecognized port into <p:empty/>
>>    f. Mark any unrecognized step in the XProc namespace as invalid
>>
>> 3. Perform static analysis on the result. You get what you get. Maybe
>>    you get errors, maybe you don't. Maybe there are more independent
>>    pipeline fragments, maybe there aren't. Your gun, your bullet, your
>>    foot.
>>
>> 4. In forwards-compatible mode, it is a dynamic error (err:XD0032) to
>>    attempt to evaluate a step that is marked "invalid".
>
>> The most troubling part of this approach is the way in which "invalid"
>> has to percolate through the pipeline and be taken into consideration
>> in different places:
>
> Hmmm.  How does XSLT avoid this problem?  Some possible parallels:
>
>  1) You define a stylesheet function which in turn depends unequivocally
>     on an extension function.  function-available(your-fun) does _not_
>     tell you that you have a problem (in backward-compatibility mode).
>
>     You will unequivocally lose if you ever call that function.
>
>  2) You define a named template which unequivocally uses an
>     unimplemented extension instruction element.  There is no way to
>     test whether a named template will fail, but you will
>     unequivocally lose if you ever call that template.

The way that XSLT *isn't* parallel is in the requirement to build a
dependency graph.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Nearly every complex solution to a
http://nwalsh.com/            | programming problem that I have looked
                              | at carefully has turned out to be
                              | wrong.--Brent Welch