W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > October 2009

Re: Another take on versioning

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 12 Oct 2009 12:56:38 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2ws30sg8p.fsf@nwalsh.com>
"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?


>>    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,

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

Received on Monday, 12 October 2009 16:57:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:27 UTC