Programmable XML Fallback and Impact Mechanism (PXFIM)

Ok, so here's what I end up with from the day's discussions.  It's a
fairly-small generalization from what we're talking about for RIF (that
the WG seems pretty comfortable with), to cover all (namespaced) XML.
Obviously this is quick-and-dirty write-up, but maybe it gets the idea
across.   Maybe the abstract enough....

     - s

================================================================


/== Programmable XML Fallback and Impact Mechanism (PXFIM)

== Abstract == 

PXFIM provides forward compatiblity for XML-based languages deployed
on the Web, allowing them to evolve in place and to be extended by
users independently.  It does this by allowing creators of extensions,
new languages, and new language versions to publish "fallback"
information, including "impact" data.  This information is used by
PXFIM processors to translate documents from new (unimplemented)
formats into old (implemented) ones as needed.

== Operational Model ==

Conceptually, a PXFIM processor is a frontend, in front of normal
XML-consuming software.  Before the regular software consumes any XML
document, the PXFIM processor has a chance to transform the document.

When deployed, the PXFIM processor is configured with a set of XML
Schemas for validating the documents it is allowed to pass to the
backend.  These schemas communicate to PXFIM which XML languages the
backend implements.  They should be written "tightly", so they do
*not* accept anticipated future versions the languages.

The PXFIM processor is also configured with a table of weights for
different kinds of "impacts".  This table will be application
specific, as detailed [below].

== The Algorithm ==

Here's what a PXFIM processor must do:

1.  Try to validate the input document against each of the backend
    schemas.   If it validates against any of them, pass it through
    and we're done.   Otherwise:

2.  Parse the input document for any PXFIM declarations and PXFIM
    import-control information.

3.  If there is no PXFIM import-control information, or if there is
    and it allows it, dereference all the namespaces used in the
    document.  [@@ some issues about rdf-style URIs, but this is close
    enough for now.]  The returned content should contain more PXFIM
    declarations or be (somehow) linked to other documents which do.

4.  Use these PXFIM declarations [ and maybe others? ] to find the
    minimal-impact fallback path from the input to one of the backend
    acceptable schemas.    Each step on the fallback path is an XSLT
    which transforms a document from a "new" format to an "old" one,
    possibly changing the meaning or other characterisitcs. These
    changes indicated by the associated "impact" information.

5.  If there is such a path, perform the fallbacks, and pass the result
    to the backend along with the accumulated impact flags.  If there is
    not one, let the backend know that fallback is not possible for this
    document.

== Example Scenario ==

A new XML language, PianoML is developed for communicating information
about pianos.  The first version, 1.0, is adopted by several
organizations that buy and sell pianos, as well as music schools, moving
companies, and a few musicians.  It allows them to pass around
information about specific pianos (eg Steinway piano #212640, which has
alligatored finish and curve-tapered legs).  Their inventory systems and
various other software is modified to read and write this format.
[ It took me several tries to come up with a FooML that didn't really
exist.  :-) ]

After some time, it becomes clear that some useful fields were left
out.  In version 1.0, there was a one-bit flag saying whether the
tuning pegs tended to slip.  For version 1.1, some users wanted
detailed information about which pegs tended to slip, and how strong
the tendency was.  This could easily be added, but how would the
software written to handle PianoML 1.0 files respond?  Some systems
would probably fail, some would ignore the new information, some might
do other odd things.

Fortunately, the PianoML 1.0 specification mandated PXFIM processors
for PianoML consumers.  Because of this, the creators of PianoML 1.1
could publish PXFIM declarations linked from the PianoML 1.1 namespace
document and reasonably expect them to followed.  These declarations
were written to include a fallback procedure which removed the
detailed information about pegs slipping, and set the some-pegs-slip
flag if one or more of them were stated as slipping with a tendency of
more than 20%.

Late on, some moving companies realized it would be helpful to them to
further extend PianoML with information helpful to them about which
kind of bolts needed to be removed to remove the piano's legs.  The
other communities using PianoML were resistant to this information
being included -- it was of no interest to them.  However, the moving
companies were free to include it, written in their own extension (in
their own namespace), because they also published PXFIM declarations
which simply said the information could be silently dropped if the
backend schemas didn't allow it.

Received on Wednesday, 7 November 2007 03:58:42 UTC