W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2009

Limited_Forward_Compatibility

From: Sandro Hawke <sandro@w3.org>
Date: Thu, 02 Apr 2009 14:16:15 -0400
To: csma@ilog.fr
cc: public-rif-wg@w3.org
Message-ID: <7621.1238696175@ubehebe>

Comments on 
    http://www.w3.org/2005/rules/wiki/Limited_Forward_Compatibility

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.  In a few cases I ask questions where I'll try to do more
research if no one happens to have a handy answer.

Questions/notes:

* 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.

* 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?  I guess we don't
  really need to do anything; some crazy soul (like myself) can write a
  RIF_on_RIF_as_Frame-to-XSLT_on_RIF_as_XML translator....  Okay, never
  mind.  (I was really hoping to be able to show that writing RIF
  transformations in RIF was easy and practical, but it's looking rather
  unlikely I'll have that done by LC, so I'll give up.)

* 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.

  Basically, every RIF document can/should have some metadata keeping
  track of how much damage was done to it during translation.  This
  doesn't just apply just to fallback processing.  When I'm turning some
  prolog into BLD, I may do all sort of damage to it, accumulating
  impact.  If we had a way to track that -- a way for my translator to
  record that while it was able to maintain soundness, it lost
  completeness, then downstream processors could decide whether to
  reject the ruleset or use it anyway, depending on their application.

  So, if this metadata is there anyway, added by translators-to-RIF,
  then these XSLT transforms can re-write the metadata, adding more
  impact.  My open questions here are:

       -- exactly what format to use...  (Is the normal RIF metadata
          might be too hard for XSLT to add to?  I don't know yet.)

       -- should it only be allowed on the Document, or can it go on any
          element?  (Only at the document level would be simpler, but
          maybe there's some important reason to target a spot where
          some impact occured.)

       -- do we stick with my old four categories:

              -- soundness (you might get incorrect answers)
              -- completeness (you might not get some correct answers)
              -- performance (you might be in a different complexity class)
              -- presentation (names of variables, structure of rules, etc,
                               has changed)

          or is there something else?  Those four seem to have held up
          over the years since then, at least in my head.

       -- for each catagory, do we just use 1 bit (yes/no), 2 bits
          (none/minor/medium/severe), or a lots (0..1)?  I'm quite torn
          on this.  The flexibility of a number seems nice, but I
          understand that unless we can say what the number means, it
          might do more harm than good.  In any case, there should
          probably be a text explanation of the impact as well.  (XTAN
          wanted a number so it could pick the lowest-impact transform;
          I don't see this implementations having as many choices here,
          so the need of a number is less.)

* 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 approaches:

     1.  Allow the declaration to go at the top of the document, not
         on the elements themselves, and even allow them to be xincluded.
         So instead of:

            ...
            <rif:behavior fallback="step-in">
            ...
            <Do fallback="http://www.w3.org/2005/rules/wiki/FallbackDo2And.xsl">
            ...

         at top of the document you'd say something like:

            <Document>
               <fallback>
                  <StepIn element="rif:behavior" />
               </fallback>
               <fallback>
                  <Transform 
                     element="rif:Do" 
                     location=
                        "http://www.w3.org/2005/rules/wiki/FallbackDo2And.xsl"
                  />
               </fallback>

         and then later, you could just use rif:behavior and rif:Do
         without the fallback attributes.

         The big win here is that the stuff at the top becomes standard
         boiler-plate, and can be included by reference, eg with
         xinclude.  (Otherwise it's littered all over every document
         that uses any kind of syntactic sugar.)

     2.  Taking this one step farther (in a direction XTAN did), we
         could say those declarations are obtained using the namespace
         URLs, so the author of an instance document never has to worry
         about them.

         (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.)

* In all the cases that involve URLs...
       - the XSLTs in csma's proposal as written
       - the xinclude or namespace de-referencing in my suggestion,
         above
  there are concerns about off-line processing and security.

  I suggest these be handled by saying that the definitive data is
  provided in the spec of the dialect or extension (updated via
  published errata and new editions), and that the on-line data is
  available as a convenience for applications that happen to be on-line
  and not need very high security.  The URLs never need to be
  dereferenced; they are just identifiers for fallback configuration
  information and transforms.

* Where should this text go?  Our specs are kind of upside-down.   :-)
  Normally, I would think this would go in Core, but the XML syntax for
  Core is specified in BLD, so.....  *shrug*

I think that's it...

      - Sandro
Received on Thursday, 2 April 2009 18:16:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:04 GMT