W3C home > Mailing lists > Public > public-rif-wg@w3.org > November 2006

Re: Forward-Compatibility (Extensibility) Requirement & Proposal

From: Christian de Sainte Marie <csma@ilog.fr>
Date: Tue, 14 Nov 2006 16:54:34 +0100
Message-ID: <4559E6BA.1070309@ilog.fr>
To: Sandro Hawke <sandro@w3.org>
CC: public-rif-wg@w3.org

Sandro Hawke wrote:
> The requirement might be phrased like this:
>     RIF must be extensible, so that implementations can be forward
>     compatible, continuing to operate well when given RIF dialects
>     which use extensions unknown to the implementation.

Does this mean that compliance would not be related to dialtects (as in: 
this implementation is compliant to RIF dialect X and RIF dialect Y)?

On the other hand, it makes sense to require that unknown extensions (to 
a given implementation), including non-standard ones, do not break that 

> [...] Forward compatibility means progress can be
> incremental instead of revolutionary.
> The simplest approach to forward compatibility, in general, is to mark
> each extension as "must-understand" or "may-ignore". 

It also requires that the "extension points" have been well thought of 
in the to-be extended syntax. E.g., if a dialect says that an expression 
is made of a conjunction of litterals, where litterals are atoms or 
negated atoms, it will be less easily extensible that one that says that 
an expression is made of a logical operation on literals, where the only 
logical operation allowed is conjunction, and where litterals are atoms 
or modified atoms, where the only modification is negations.

> I think RIF can do better than this general must-understand/may-ignore
> approach.   Here are some intermediate categories:
>    [...]
> I think that covers the basic problem space.   

I will have to think about that a little bit more.

This is also related to "expected behaviour". What is my implementation 
does not understand something that is a "must understand", for instance?

Received on Tuesday, 14 November 2006 15:55:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:41 UTC