- From: Sandro Hawke <sandro@w3.org>
- Date: Sun, 12 Apr 2009 11:49:45 -0400
- To: Christian De Sainte Marie <csma@fr.ibm.com>
- cc: public-rif-wg@w3.org
A quick to-the-point answer (since it's Easter morning)....
Although I'm not convinced it's a good use of our resources, I'm okay
with some fallback mechanism being specified AT RISK through the end of
CR, but I think we should say in the spec that if the fallback
mechanisms ends up not included, PRD producers will be told they SHOULD
translate to Core those rulesets which can be translated to core without
a significant observable change in semantics. (I'm not sure the best
way to say that, technically, in out specs, but I hope you know what I
mean.)
(An even quicker note: the term "extended dialect" is confusing to me;
it could mean either the parent (subset) dialect, or the child
(superset) dialect. The parent is extended (by adding extensions) to
make the child, and the child is an extended version of the parent
(being the parent plus extensions). Since it makes sense to say either
one is/was 'extended', the term 'extended' doesn't distinguish between
them. I'm torn between "parent/child" and "subset/superset". The only
problem "parent/child" is that you have to picture the children being
grown up and now being bigger than the parents. :-)
-- Sandro
> Christian
>
> ********* NOTICE **********
> My new email address at IBM is: csma@fr.ibm.com
> My ILOG email address will not be forwarded after May 6
> *****************************
>
> Sandro,
>
> Thanx for the comments.
>
> Sandro Hawke wrote:
> > Comments on=20
> > http://www.w3.org/2005/rules/wiki/Limited=5FForward=5FCompatibility
> >=20
> > Short version: I think we should go ahead with this LFC proposal, modulo
> > the changes I've noted below, but consider it AT RISK, given how novel
> > it is.
>
>
> I do not know that XSLT transfoms are that novel, but I agree that the
> feature should be AT RISK until implementation proven.
>
> > Questions/notes:
> >=20
> > * Should it mandate XSLT 1 or 2? XSLT 2.0 has been a Rec for over two
> > years now, so I think we can require it, but I'm not all the familiar
> > with the market.
>
>
> There are quite a few free XSLT 1 processors available. For XSLT 2,
> there is at least Saxon. I ran my examples through msxsl (XSLT 1) and=20
> Saxon.
>
> As far as I can see, XLST 1 is enough for what I propose.
>
> > * I'd like to keep the door open to doing the re-writing in RIF instead
> > of XSLT (using the fact the RIF documents can be seen a sets of
> > frames). Any ideas how to allow such a migration? (...)
>
>
> If I understand you proposal correctly, to write the fallback rules in
> RIF, the idea is that consumer implementation would run the rules; e.g
> the fallbacks from PRD to Core would be written in Core, so that a Core
> consumer implementation could do the transforms.
>
> A first problem is that it works only if the consumer is a rule engine,
> which is not necessarily the case.
>
> More fundamentally, it seems that all the rules would have to be expressed =
>
> in Core, otherwise we would have the same scalability problem as if we=20
> required the producer to always produce RIF that is compatible with the=20
> largest possible set of dialects (e.g. require that a PRD producer always=20
> produce Core when possible).
>
> Then there is the question of how to express rewrite rules in Core.
>
> If the fallbacks are done in XSLT, style sheets are required only for=20
> the extended dialect (or closest dialect, if we talk sideward=20
> compatibility as well), as they can, then, be cascaded.
>
>
> > * The main "limit" in this proposal (compared to XTAN) is that it only
> > handles syntactic sugar -- no "approximate" fallbacks are allowed.
> > That is, there's no "impact" mechanism. It seems to me there's a
> > fairly easy way to add this kind of "do your best" processing back in,
> > and it's actually orthogonal to your proposal.
>
>
> That's right. But the proposal can be extended later.
>
> As far as I can see, the only case where we cannot do without some kind=20
> of fallback mechanism with our three dialects (Core, BLD and PRD), is=20
> the PRD action part, which can be dealt with purely syntactically: so,=20
> we do not need semantic fallbacks at this stage. (Of course, once we have=20
> it, we can use it for convenience as well :-)
>
> > Basically, every RIF document can/should have some metadata keeping
> > track of how much damage was done to it during translation. [...]
>
>
> Maybe; but this is something that can be postponed. What we need is to=20
> make sure that whatever limited extensibility mechanism we keep for phase=20
> 1 is extensibble, itself...
>
> >=20
> > * It would be nice to avoid writing all these rif:fallback attributes
> > all over the place, especially in the case of PRD fallbacks to core,
> > which are expected to be the same everywhere. Two possible=20
> approaches:
>
> I like the idea, in XTAN, of associating an URL to a dialect namespace (or =
>
> a set of dialects in the case of the RIF namespace), and to use that URL=20
> to locate a repository of all the constructs in the namespace, and having=20
> all the dialects specifications that any construct they reuse from the=20
> repository, they associate with an equivalent semantics as the semantics=20
> assigned to it in the dialect that first specified it; thus offering some=20
> kind of backward compatibility.
>
> And the idea to use that "repository" for storing fallbacks, too (I mean,=20
> I like that idea, too).
>
> Something like:
>
> <xtan:repository xmlns:rif=3D"...">
> ...
> <xtan:element name=3D"rif:And">
> <definedBy dialect=3D"RIF-Core"/>
> </xtan:element
> ...
> <xtan:element name=3D"rif:Do">
> <definedBy dialect=3D"RIF-PRD"/>
> <fallback target=3D"RIF-CORE">
> http://www.w3.org/.../fallbacks/prd2core.xsl
> </fallback>
> </xtan:element>
> ...
> </xtan:repository>
>
> When processing a RIF document and stepping into an element it does not=20
> know, a consumer implementation would retrieve, from the repository, the=20
> fallback targeted to one of the dialects it can handle, if any, where none =
>
> means "reject", etc. Of course, the fallback points to a style sheet that=20
> does all the transforms from the originating dialect (that defined the=20
> construct) to the target one (so that the consumer implementation will=20
> have to fetch the URL of the style sheet only once).
>
> Any dialect would be required to specify at least the fallback to the=20
> dialect(s) that it extends. but sidewards fallbacks could be defined as=20
> well (that is one benefit of that approach, that there can be=20
> "fallsaidewards", not only fallbacks).
>
> If we require consumer implementation to understand only the "fallback"=20
> element from XTAN, where "fallback" is for purely syntactic transforms,=20
> the approach is indefinitely extensible, isn't it? For new constructs can=20
> be added for semantic fallbacks, with severity attribute and all, that=20
> future consumer implementations may ba able to handle, but are required=20
> to.
>
> Another benefit is it can also take into account cases such as a dialect=20
> that extends an element defined by another dialect by adding an optional=20
> attribute (to extend the semantics), e.g.
>
> ...
> <xtan:element name=3D"rif:Foo">
> <definedBy dialect=3D"D">
> ...
> <xtan:attribute name=3D"rif:bar">
> <added-by dialect=3D"E"/> <!-- where E extends D, directly or
> not -->
> <fallback target=3D"...">...</fallback>
> </xtan:attribute>
> <xtan:element>
> ...
>
> And, of course, nothing would change in the RIF-XML, since the=20
> extensibility mechanism would be completely orthogonal (but Core, PRD and=20
> BLD implementation would still be required to implement at least the=20
> fallback part, of course, that feature being AT RISK).
>
> > (It's not clear to me exactly what the protocol for this,
> > however. There is still no W3C standard for namespace
> > documents. I think we can handle this, but it will be a bit
> > messy.)
>
>
> Can you be more explicit? I am not sure to understand what you mean.
>
> > * Where should this text go?=20
>
>
> In a separate document (yes, I know: one more. But that one would be=20
> fairly short), with a normative reference in the spec of each dialect.
>
> Cheers,
>
> Christian
>
> ILOG, an IBM Company
> 9 rue de Verdun
> 94253 - Gentilly cedex - FRANCE
> Tel. +33 1 49 08 35 00
> Fax +33 1 49 08 35 10
>
>
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
> Compagnie IBM France
> Si=E8ge Social : Tour Descartes, 2, avenue Gambetta, La D=E9fense 5, 92400 =
>
> Courbevoie
> RCS Nanterre 552 118 465
> Forme Sociale : S.A.S.
> Capital Social : 609.751.783,30 ?
> SIREN/SIRET : 552 118 465 02430
>
>
>
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
> Compagnie IBM France
> Si=E8ge Social : Tour Descartes, 2, avenue Gambetta, La D=E9fense 5, 92400 =
>
> Courbevoie
> RCS Nanterre 552 118 465
> Forme Sociale : S.A.S.
> Capital Social : 609.751.783,30 ?
> SIREN/SIRET : 552 118 465 02430
>
>
>
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
> Compagnie IBM France
> Si=E8ge Social : Tour Descartes, 2, avenue Gambetta, La D=E9fense 5, 92400 =
>
> Courbevoie
> RCS Nanterre 552 118 465
> Forme Sociale : S.A.S.
> Capital Social : 609.751.783,30 ?
> SIREN/SIRET : 552 118 465 02430
>
>
> --=_alternative 0038E458C1257595_=
> Content-Type: text/html; charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
>
> <br><font size=3D2 face=3D"sans-serif">Sandro, I cannot succeed posting on
> the mailing list from my new IBM account. Don't know why.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Can you post my answers on my behalf,
> please (and read them, since you seem to be the one most interested in
> the subject :-)</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Thanx,</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Christian</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">********* NOTICE **********<br>
> My new email address at IBM is: csma@fr.ibm.com<br>
> My ILOG email address will not be forwarded after May 6<br>
> *****************************</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Sandro,</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Thanx for the comments.</font>
> <br><font size=3D2 face=3D"sans-serif"><br>
> Sandro Hawke wrote:</font>
> <br><font size=3D2 face=3D"sans-serif">> Comments on </font>
> <br><font size=3D2 face=3D"sans-serif">> </font><a href=3D=
> http://www.w3.org/2005/rules/wiki/Limited=5FForward=5FCompatibility><font s=
> ize=3D2 face=3D"sans-serif">http://www.w3.org/2005/rules/wiki/Limited=5FFor=
> ward=5FCompatibility</font></a>
> <br><font size=3D2 face=3D"sans-serif">> </font>
> <br><font size=3D2 face=3D"sans-serif">> Short version: I think we should
> go ahead with this LFC proposal, modulo</font>
> <br><font size=3D2 face=3D"sans-serif">> the changes I've noted below, b=
ut
> consider it AT RISK, given how novel</font>
> <br><font size=3D2 face=3D"sans-serif">> it is.</font>
> <br>
> <br>
> <br><font size=3D2 face=3D"sans-serif">I do not know that XSLT transfoms are
> that novel, but I agree that the</font>
> <br><font size=3D2 face=3D"sans-serif">feature should be AT RISK until impl=
> ementation
> proven.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">> Questions/notes:</font>
> <br><font size=3D2 face=3D"sans-serif">> </font>
> <br><font size=3D2 face=3D"sans-serif">> * Should it mandate XSLT 1 or 2?
> XSLT 2.0 has been a Rec for over two</font>
> <br><font size=3D2 face=3D"sans-serif">> years now, so I think we
> can require it, but I'm not all the familiar</font>
> <br><font size=3D2 face=3D"sans-serif">> with the market.</font>
> <br>
> <br>
> <br><font size=3D2 face=3D"sans-serif">There are quite a few free XSLT 1 pr=
> ocessors
> available. For XSLT 2,</font>
> <br><font size=3D2 face=3D"sans-serif">there is at least Saxon. I ran my ex=
> amples
> through msxsl (XSLT 1) and Saxon.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">As far as I can see, XLST 1 is enough
> for what I propose.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">> * I'd like to keep the door open
> to doing the re-writing in RIF instead</font>
> <br><font size=3D2 face=3D"sans-serif">> of XSLT (using the fact
> the RIF documents can be seen a sets of</font>
> <br><font size=3D2 face=3D"sans-serif">> frames). Any ideas
> how to allow such a migration? (...)</font>
> <br>
> <br>
> <br><font size=3D2 face=3D"sans-serif">If I understand you proposal correct=
> ly,
> to write the fallback rules in</font>
> <br><font size=3D2 face=3D"sans-serif">RIF, the idea is that consumer imple=
> mentation
> would run the rules; e.g</font>
> <br><font size=3D2 face=3D"sans-serif">the fallbacks from PRD to Core would
> be written in Core, so that a Core</font>
> <br><font size=3D2 face=3D"sans-serif">consumer implementation could do the
> transforms.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">A first problem is that it works only
> if the consumer is a rule engine,</font>
> <br><font size=3D2 face=3D"sans-serif">which is not necessarily the case.</=
> font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">More fundamentally, it seems that all
> the rules would have to be expressed in Core, otherwise we would have the
> same scalability problem as if we required the producer to always produce
> RIF that is compatible with the largest possible set of dialects (e.g.
> require that a PRD producer always produce Core when possible).</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Then there is the question of how to
> express rewrite rules in Core.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">If the fallbacks are done in XSLT, s=
> tyle
> sheets are required only for </font>
> <br><font size=3D2 face=3D"sans-serif">the extended dialect (or closest dia=
> lect,
> if we talk sideward </font>
> <br><font size=3D2 face=3D"sans-serif">compatibility as well), as they can,
> then, be cascaded.</font>
> <br>
> <br>
> <br><font size=3D2 face=3D"sans-serif">> * The main "limit" in
> this proposal (compared to XTAN) is that it only</font>
> <br><font size=3D2 face=3D"sans-serif">> handles syntactic sugar
> -- no "approximate" fallbacks are allowed.</font>
> <br><font size=3D2 face=3D"sans-serif">> That is, there's no &quo=
> t;impact"
> mechanism. It seems to me there's a</font>
> <br><font size=3D2 face=3D"sans-serif">> fairly easy way to add t=
> his
> kind of "do your best" processing back in,</font>
> <br><font size=3D2 face=3D"sans-serif">> and it's actually orthog=
> onal
> to your proposal.</font>
> <br>
> <br>
> <br><font size=3D2 face=3D"sans-serif">That's right. But the proposal can be
> extended later.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">As far as I can see, the only case w=
> here
> we cannot do without some kind </font>
> <br><font size=3D2 face=3D"sans-serif">of fallback mechanism with our three
> dialects (Core, BLD and PRD), is </font>
> <br><font size=3D2 face=3D"sans-serif">the PRD action part, which can be de=
> alt
> with purely syntactically: so, </font>
> <br><font size=3D2 face=3D"sans-serif">we do not need semantic fallbacks at
> this stage. (Of course, once we have it, we can use it for convenience
> as well :-)</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">> Basically, every RIF doc=
> ument
> can/should have some metadata keeping</font>
> <br><font size=3D2 face=3D"sans-serif">> track of how much damage
> was done to it during translation. [...]</font>
> <br>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Maybe; but this is something that can
> be postponed. What we need is to make sure that whatever limited extensibil=
> ity
> mechanism we keep for phase 1 is extensibble, itself...</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">> </font>
> <br><font size=3D2 face=3D"sans-serif">> * It would be nice to avoid wri=
> ting
> all these rif:fallback attributes</font>
> <br><font size=3D2 face=3D"sans-serif">> all over the place, espe=
> cially
> in the case of PRD fallbacks to core,</font>
> <br><font size=3D2 face=3D"sans-serif">> which are expected to be
> the same everywhere. Two possible approaches:</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">I like the idea, in XTAN, of associa=
> ting
> an URL to a dialect namespace (or a set of dialects in the case of the
> RIF namespace), and to use that URL to locate a repository of all the const=
> ructs
> in the namespace, and having all the dialects specifications that any const=
> ruct
> they reuse from the repository, they associate with an equivalent semantics
> as the semantics assigned to it in the dialect that first specified it;
> thus offering some kind of backward compatibility.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">And the idea to use that "repos=
> itory"
> for storing fallbacks, too (I mean, I like that idea, too).</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Something like:</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif"><xtan:repository xmlns:rif=3D&quo=
> t;..."></font>
> <br><font size=3D2 face=3D"sans-serif">...</font>
> <br><font size=3D2 face=3D"sans-serif"><xtan:element name=3D"rif:An=
> d"></font>
> <br><font size=3D2 face=3D"sans-serif"> <definedBy dialect=
> =3D"RIF-Core"/></font>
> <br><font size=3D2 face=3D"sans-serif"></xtan:element</font>
> <br><font size=3D2 face=3D"sans-serif">...</font>
> <br><font size=3D2 face=3D"sans-serif"><xtan:element name=3D"rif:Do=
> "></font>
> <br><font size=3D2 face=3D"sans-serif"> <definedBy dialect=
> =3D"RIF-PRD"/></font>
> <br><font size=3D2 face=3D"sans-serif"> <fallback target=3D&=
> quot;RIF-CORE"></font>
> <br><font size=3D2 face=3D"sans-serif"> </font><a=
> href=3Dhttp://www.w3.org/.../fallbacks/prd2core.xsl><font size=3D2 face=3D=
> "sans-serif">http://www.w3.org/.../fallbacks/prd2core.xsl</font></a>
> <br><font size=3D2 face=3D"sans-serif"> </fallback></font>
> <br><font size=3D2 face=3D"sans-serif"></xtan:element></font>
> <br><font size=3D2 face=3D"sans-serif">...</font>
> <br><font size=3D2 face=3D"sans-serif"></xtan:repository></font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">When processing a RIF document and s=
> tepping
> into an element it does not know, a consumer implementation would retrieve,
> from the repository, the fallback targeted to one of the dialects it can
> handle, if any, where none means "reject", etc. Of course, the
> fallback points to a style sheet that does all the transforms from the
> originating dialect (that defined the construct) to the target one (so
> that the consumer implementation will have to fetch the URL of the style
> sheet only once).</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Any dialect would be required to spe=
> cify
> at least the fallback to the dialect(s) that it extends. but sidewards
> fallbacks could be defined as well (that is one benefit of that approach,
> that there can be "fallsaidewards", not only fallbacks).</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">If we require consumer implementation
> to understand only the "fallback" element from XTAN, where "=
> fallback"
> is for purely syntactic transforms, the approach is indefinitely extensible,
> isn't it? For new constructs can be added for semantic fallbacks, with
> severity attribute and all, that future consumer implementations may ba
> able to handle, but are required to.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Another benefit is it can also take
> into account cases such as a dialect that extends an element defined by
> another dialect by adding an optional attribute (to extend the semantics),
> e.g.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">...</font>
> <br><font size=3D2 face=3D"sans-serif"> <xtan:element name=
> =3D"rif:Foo"></font>
> <br><font size=3D2 face=3D"sans-serif"> <defin=
> edBy
> dialect=3D"D"></font>
> <br><font size=3D2 face=3D"sans-serif"> ...</font>
> <br><font size=3D2 face=3D"sans-serif"> <xtan:=
> attribute
> name=3D"rif:bar"></font>
> <br><font size=3D2 face=3D"sans-serif"> &=
> nbsp;<added-by
> dialect=3D"E"/> <!-- where E extends D, directly or</font>
> <br><font size=3D2 face=3D"sans-serif"> &=
> nbsp;
>
> not --></font>
> <br><font size=3D2 face=3D"sans-serif"> &=
> nbsp;
> <fallback target=3D"...">...</fallback><=
> /font>
> <br><font size=3D2 face=3D"sans-serif"> </xtan=
> :attribute></font>
> <br><font size=3D2 face=3D"sans-serif"> <xtan:element></f=
> ont>
> <br><font size=3D2 face=3D"sans-serif">...</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">And, of course, nothing would change
> in the RIF-XML, since the extensibility mechanism would be completely ortho=
> gonal
> (but Core, PRD and BLD implementation would still be required to implement
> at least the fallback part, of course, that feature being AT RISK).</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">> &nb=
> sp;(It's
> not clear to me exactly what the protocol for this,</font>
> <br><font size=3D2 face=3D"sans-serif">> &nb=
> sp;however.
> There is still no W3C standard for namespace</font>
> <br><font size=3D2 face=3D"sans-serif">> &nb=
> sp;documents.
> I think we can handle this, but it will be a bit</font>
> <br><font size=3D2 face=3D"sans-serif">> &nb=
> sp;messy.)</font>
> <br>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Can you be more explicit? I am not s=
> ure
> to understand what you mean.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">> * Where should this text go? </=
> font>
> <br>
> <br>
> <br><font size=3D2 face=3D"sans-serif">In a separate document (yes, I know:
> one more. But that one would be fairly short), with a normative reference
> in the spec of each dialect.</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Cheers,</font>
> <br>
> <br><font size=3D2 face=3D"sans-serif">Christian<br>
> <br>
> ILOG, an IBM Company<br>
> 9 rue de Verdun<br>
> 94253 - Gentilly cedex - FRANCE<br>
> Tel. +33 1 49 08 35 00<br>
> Fax +33 1 49 08 35 10<br>
> <br>
> <br>
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:<br>
> Compagnie IBM France<br>
> Si=E8ge Social : Tour Descartes, 2, avenue Gambetta, La D=E9fense 5, 92400
> Courbevoie<br>
> RCS Nanterre 552 118 465<br>
> Forme Sociale : S.A.S.<br>
> Capital Social : 609.751.783,30 €<br>
> SIREN/SIRET : 552 118 465 02430<br>
> <br>
> <br>
> <br>
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:<br>
> Compagnie IBM France<br>
> Si=E8ge Social : Tour Descartes, 2, avenue Gambetta, La D=E9fense 5, 92400
> Courbevoie<br>
> RCS Nanterre 552 118 465<br>
> Forme Sociale : S.A.S.<br>
> Capital Social : 609.751.783,30 €<br>
> SIREN/SIRET : 552 118 465 02430<br>
> <br>
> <br>
> <br>
> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:<br>
> Compagnie IBM France<br>
> Si=E8ge Social : Tour Descartes, 2, avenue Gambetta, La D=E9fense 5, 92400
> Courbevoie<br>
> RCS Nanterre 552 118 465<br>
> Forme Sociale : S.A.S.<br>
> Capital Social : 609.751.783,30 €<br>
> SIREN/SIRET : 552 118 465 02430<br>
> <br>
> </font>
> --=_alternative 0038E458C1257595_=--
Received on Sunday, 12 April 2009 15:49:56 UTC