let's not have a fallback mechanism (proposal)

I'm thinking that we wont have time to address extensibility with any
kind of a fallback mechanism, but I also think we don't need to.

The most urgent deadline is that while we could let a spec for a
fallback mechanism lag a little behind the others until Rec, I don't
think we can go to Last Call on all the specs without having the
fallback mechanism spec even at FPWD.  And I don't think we have
anything like real consensus on a design, let alone on a spec for that
design.

Fortunately, I'm now convinced we don't need it.   

What do/did we want it for?  I see three things.  I'll give concrete
examples of each, but in each case I'm sure it's an instance of a more
general desire.  (And I apologize if I've gotten any of the technical
details wrong; I suspect I made some minor mistakes but that they don't
change the basic argument.)

   1.  We want PRD rulesets which could be machine-translated into Core
       to be consumable by Core systems.  Specifically, if the ruleset
       has ASSERT as its only action (and otherwise meets the syntactic
       restrictions of Core), a program can translate it into a Core
       ruleset.  (Generally: lossless translation to a parent (subset)
       dialect, aka de-sugaring.)

   2.  We want PRD rulesets which could be machine-translated into BLD
       to be consumable by BLD systems.  Specifically, if a PRD ruleset
       could be translated into Core except for the use of "New", then
       it could be translated into BLD using Skolemization.  (Generally:
       lossless translation to a sibling dialect; also de-sugaring, but
       with n-squared scaling with the number of dialects.  However, at
       this point, we have a very small number of sibling dialects.)

   3.  We want graceful degradation (or controlled fallback), to allow
       new features to be added to the language by user communities,
       vendors and future standards efforts, with predicatable (and
       hopefuly minimal) impact on existing users.  

While I love the elegant way XTAN handles each of these cases, I think
RIF will be okay without any fallback mechanism.   Specifically:

   For case 1:  We say that PRD systems MUST (or SHOULD?) translate to Core
                any ruleset which *can* be translated to Core.  The
                receiving system will still handle it properly, since
                it's suppose to handle Core rulesets properly.  Metadata
                can be added to signal that this translation was done,
                if it's important to know when doing the reverse
                translation.

   For case 2:  BLD consuming systems can implement this translation if
                they want.  They'll be systems which implement
                BLD-plus-some-PRD.

   For case 3:  We define a model of processing where consumers MUST
                reject documents outside the language they implement,
                and extensions MUST extend the XML syntax, so that the
                use of an extension in a document is obvious (and will
                cause rejection by systems which don't implement the
                extension.)  These are "must-understand" extensions;
                "may-ignore" extensions can just use metadata.

Some day, if XTAN gets done (someone want to fund me to work on it?)  it
can be dropped in to improve the situation, giving systems which choose
to use it the ability to consume more rulesets.  (If its use were
mandated, then producers wouldn't have to do the translation in case 1,
and all the work could be done on the receiving end, but alas, that's
not practical right now.)

That's it.  Did I miss anything?

     -- Sandro

Received on Thursday, 9 April 2009 23:23:30 UTC