Re: Forward-Compatibility (Extensibility) Requirement & Proposal

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.

I agree that what we mean is forward compatibility. An interesting 
discussion of this in the XML world (which I think I may have posted 
before) is [1]. Though the key assumption in there which makes it hard 
is that version k processors can only access version j (<k) schemas and 
your proposal gets round that.

> Here's a rough proposal for an extensibility mechanism:
> 
>    * when you're parsing RIF XML and see a syntactic element you don't
>      recognize, you turn it into a URI (by concatenating the namespace
>      part and the local part of the element tag) and dereference the
>      URI to get information about the syntactic element.  The
>      information includes, at least, the consequences of ignoring the
>      element (as above).

 >    * as a work-around for dereference not being available, RIF
 >      documents could include that information as well.

How about a very slight tweak to that? The URI (formed as above) 
*identifies* the syntactic element. The corresponding schema information 
and metadata information can be obtained by a variety of mechanisms 
including:

  o dereference of the URI (with some defined content negotiation)

  o inline inclusion of a map from the URI to a definition

  o out-of-line inclusion (i.e. some explicit import mechanism) of a set
    of URI to definition maps

  o built in knowledge

The advantage of saying the URI is the identity rather than just the 
location is that it means you don't *have* to dereference. If you 
recognize the URI by whatever means then you can process it without 
having to implement runtime dereference. Though I guess we would 
recommend that the information SHOULD be published at the URI anyway.

It also makes it easy to express the metadata about the element using 
RDF statements with the element URI as the subject. Such metadata would 
include the various categories of must-understand that you sketched out 
as well as the schema information.

An import mechanism would make it possible to bundle up a series of 
different extensions into a single dialect URL which can be imported in 
one go.

Cheers,
Dave

[1] http://types.bu.edu/seminar-documents/Versioning.pdf

Received on Thursday, 9 November 2006 20:06:55 UTC