Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document and the associated technology are being developed to meet the needs of the Rule Interchange Format (RIF) Working Group. The technology, however, is applicable in many areas beyond RIF, so this document is written to avoid using RIF as more than an example. Standardizing this work in this general form is likely to be out-of-scope for the RIF WG.
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.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Please send comments to sandro@w3.org with a subject including the text "PXFIM". Please "Cc" www-archive@w3.org, so that a public record is made of the mail.
This is not a W3C Working Draft. Even if it were: Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
PXFIM allows XML-based languages to evolve and grow, on the Web, without the need for either central coordination or the foresight to know what changes might someday be desired. It does this, leveraging Web Architecture and Semantic Web ideas, by defining a pre-processor for XML consuming software which downloads XSLT programs as necessary (when possible) to transform documents into a format the consuming software can properly handle.
All these use cases begin like this: some individual or organization (the "original author") publishes a stable specification ("version 1.0") for an XML-based language. The author intends the language to be adopted and used in a large and diverse community. The use cases below concern things which might happen after the publication of version 1.0.
New "Forked" Version of a Language: ...
New Experimental Version of a Language: ...
Official Extension to a Language: ...
User Extension to a Language: ...
Official Profile to a Language: ...
User Profile to a Language: ...
Competing Languages: ...
The Rule Interchange Format (RIF) Working Group was chartered, in part, to "construct an extensible format for rules." This requirement comes from the realities of the rule systems market and rule technologies. There are different rule technologies, which overlap in markets, but which have quite different strengths, so for some applications one particular style of engine is likely to be best. The interchange format (RIF) therefore needs to be a family of languages aligned to the different rule technologies.
For example, essentially all rule engines implement "datalog" rules. These rules are sufficient for some types of applications. (Many financial services rulebases used only datalog rules). So RIF has a "Core Dialect" for datalog rules. Many users, however, want additional features, and more powerful styles of engines are common, such as the Prolog-like logic languages, CLIPS-like "production rule" systems, and Event-Condition-Action rules. The goal is that when users writing for any of these system happen to only write datalog rules, their rulesets will run, without modification, on RIF systems as well.
@@@ how much detail to go into?
@@@ very rough; probably too contrived. Maybe just use books? It took several guesses to come up with a domain that is not addressed with some FooML.
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.
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.
Copy from RIF Extensibility Design Choices and edit to be not RIF-specific.
We use the terms XML-based language, XML-based format, XML language, and XML format interchangeably. The word "language" suggests something with a more complex grammar than "format", but that difference is immaterial to PXFIM.
@@@ talk about Language Conflict, Invisible Extensions, coordinating creators via namespace documents
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].
Here's what a PXFIM processor must do:
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:
Parse the input document for any PXFIM declarations and PXFIM import-control information.
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.
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.
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.
build up from RIF sketch of adding NAF to BLD
full details, including security model
RIF Core-to-BLD example, as per RIF Action-373.
Others?