- From: Christian de Sainte Marie <csma@ilog.fr>
- Date: Tue, 10 Feb 2009 13:34:15 +0100
- To: Gary Hallmark <gary.hallmark@oracle.com>
- CC: RIF WG <public-rif-wg@w3.org>
Gary Hallmark wrote: > 1. your xslt would transform Do(Retract(?x)) to And(Retract(?x)) -- not > legal Core Right. That's exactly why the transform does not need be conditional: either the Do contains only assertions, and the result is legal Core, and can be processed by Core. Or it contains something else (in Gary's example: a retraction), and when the consumer Core implementation will hit the <Retract> element and check its fallback value, it will find that it is "reject" and it will reject the document... > 2. your xslt would transform Do(Assert(eg:P(?x))) to And(eg:P(?x)) -- > not legal Core either, but could easily be added I guess Yes, I did not go as far as replacing "And(p)" by "p". That's because I thought that "And(p)" was legal Core: isn't it the case? I see that the EBNF in section 2.6.2 does not account for that case, indeed; but sections 2.1 to 2.5 do not say anything about that restriction wrt BLD, either... Anyway, if And(p1...pn) is not legal in a Core conclusion, the XSLT has to be changed to take that into account. Noreal difficulty, here. > 3. I have no idea how this helps resolve object VS frame That's because I did not include that discussion with my strawman proposal, because I thought that something like that was already needed, anyway, to fallback from BLD to Core (fall back from named-argument to positional terms) and from PRD to Core (fallbacks for Do, bounded variables, nested forall). But, if we decide to do something like that, then it opends new doors... Wrt the object VS frame discussion, for instance, the idea is that, if we adopt that proposal, we can include an object-like construct with single valued attributes, and the associated action to modify the value of an attribute, where the object-like construct would fallback to frames, and the presence or absence of the action in the conclusion would make the difference whether the document is Core compatible or not (the fallback for the modify action being, of course, "reject"). Thus, we would have both the object-like construct that Changhai wants and renounce nothing of the interoperability with Core, thus making everybody happy... Cheers, Christian > Christian de Sainte Marie wrote: > >> All, >> >> Trying to find a resolution to the "object VS frame" discussion, that >> would reconcile the requirement for maximal interoperability between >> PRD and Core, and the demand for dialect-specific idioms (as part of >> the requirement for easy implementability and wide adoptability), I >> came back to exploring the feasibility of some kind of simple >> extensibility mechanism... >> >> And I came to two conclusions: >> - There is a quite simple solution, using XSLT, that enables a form of >> limited forward compatibility between extended and extending dialects; >> - Such a mechanism is desirable even if we do not add new specific >> syntax to what PRD already has (for several reasons, but one, with >> which I expect everybody will agree, is scalability). >> >> I wrote a strawman proposal [1], with a couple examples, and I tried a >> complete, if simple, example to check feasibility. You will find >> attached: >> - a file called PRDex.xml, that contains a PRD-fied version of the >> complete example in BLD; >> - a file called COREex.xml, that contains a COREified version of the >> same; >> - a file called do2and.xsl, that contains the XSLT stylesheet that I >> used to produce COREex.xml from PRDex.xml (I tested it with msxsl and >> saxon9). >> >> [1] http://www.w3.org/2005/rules/wiki/Limited_Forward_Compatibility >> >> What makes me believe that the solution I propose is simple, is that I >> did not know anything about XSLT only 10 days ago, and I believe, now, >> that I could write, in a matter of days, the complete XSLT stylesheet >> for all the fallbacks needed to provide limited forward compatibility >> to Core wrt PRD as it stands today (and some more :-) >> >> Does this make sense? >> >> Cheers, >> >> Christian >> > >
Received on Tuesday, 10 February 2009 12:35:12 UTC