- From: Sandro Hawke <sandro@w3.org>
- Date: Thu, 09 Apr 2009 19:23:20 -0400
- To: public-rif-wg@w3.org
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