- From: Sandro Hawke <sandro@w3.org>
- Date: Tue, 06 Nov 2007 22:58:30 -0500
- To: connolly@w3.org
- Cc: www-archive@w3.org
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