XTAN

Forward compatibility is needed for web-scale systems to improve. ("There is no one administrator")

Making languages extensible -- predicting the future -- is too hard.

XML Transform-As-Needed (XTAN) may solve this problem (at some cost).

XTAN:

You receive a document you don't understand
Dereference the namespace to learn about transforms
Transform it into something you do understand
Assess the impact and (if usable) proceed

I'm here to talk about a new approach to forward compatibility. The approach is simply this: when you get an XML document you don't understand, you use the namespace URIs to lookup instructions for transforming it into something you do understand.

My claim is that in many cases this is a practical solution to the problem of versioning languages -- which is really a critical problem in building decentralized systems -- and it should be standardized and widely adopted.

This Talk

High Level View
Low Level Details
Examples

High Level View

My background / Semantic Web (Context)
XTAN's background / RIF (Context)
Alice and Bob (Problem Statement)
Other Approaches
XTAN Sketch for <blink>
XTAN Sketch for <table>

My background / Semantic Web (Context)

W3C "Semantic Web Activity" (not "XML Activity")
... so my approach to XML may be odd
RDF vs XML: friendly rivalry? (learn from each other)

XTAN's background / RIF (Context)

Rule Interchange Format (RIF) Working Group
"a core rule language plus extensions"
Impractical to analyze all likely extensions
Constraints like: must be schema valid (working from Java)
XTAN may be RIF-WG Working Draft soon-ish

Alice and Bob (Problem Statement)

Older system Alice, implements alpha
Bob implements beta
Assume beta is superset of alpha (BC)
Alice can send to Bob without difficulty.
When Bob sends to Alice in the alpha subset, no problem
If Bob sends to Alice outside the alpha subset, what should Alice do?

This is the Forward Compatibility problem. What should the spec for alpha say?

Motivating Forward Compatibility

What if Alice rejects beta documents?

Bob has a difficult choice:

Publish in beta, alienating users like Alice
Publish in alpha, and lose the benefits of adopting beta.

For the system to move forward, Bob needs to be able to publish in beta without causing problems for Alice.

RIF Translation Diagram

Approaches to Forward Compatibility

Bob publishes both (eg HTTP Content Negotiation)
Alice uses fixed repair algorithm (eg HTML)
Fallback instructions/content in instance document (eg #ifdef)
Alpha includes "future expansion" slots
"Languages Should be Extensible"

XTAN Sketch for <blink>

If HTML had always had XTAN (and XML with namespaces), then browsers which didn't implement <blink> could have followed this process:

Browser gets unrecognized <blink> element
Browser uses namespace to get schema+annotations
Multiple fallbacks are available: blink can be rewritten to use javascript (if available), CSS text-decoration: blink (if available), or just <b>. "Best" fallback transform is chosen.
Browser renders the transformed content.

XTAN Sketch for <table>

For "table" there is no good fallback. Whatever we do will be very lossy.

Replace <table> element with <pre> element with laid-out content?
Use CSS absolute positioning?
Replace with text explaining table markup?
Just delete table markup? (HTML default)

At least with XTAN, the developers of "table" have a choice.

Low Level Details

This is a first-pass design.

Pre-processor
Lookup
Features
Transforms
Impact
Routing

Pre-Processor

Job: transform input document into desired input language

conceptually a front-end, before XML parser
could be integrated

Parameters:

Input document
List of allowed (implemented) syntactic features
(optional) cost/weights for impact areas

Command-line version (partial usage statement):

Usage: xtan [options] input-location

Options:
  -F FEATURES, --allowed-feature=FEATURES
                        Add this feature to the set of implemented features
  -W WEIGHTS, --weight=WEIGHTS
                        Add weight co-efficient for given impact type, format
                        is like '0.25 performance'

Lookup

Assume namespace document == XML schema
Should perhaps use RDDL, RDDL2, GRDDL, Con-Neg, etc
Data in annotation/appinfo elements

Features

A "feature" groups syntactic structures (cf HTTP Versions)
... so they can be removed together (see "routing")
Presence indicated by XML elements
(You can't safely change the meaning of a tag. Just add new tags.)
Currently just named with opaque strings; should be URIs
Use syntactic structures/structures instead of version identifiers (since producers can't know all interesting subsets)

<xs:schema 
...
  <xs:element name="a" type="xs:string">
    <xs:annotation xtan:mayIndicate="feature-a"/>
  </xs:element>
</xs:schema>

Transforms

Delete subtree
Replace subtree with its content
Replace subtree with fixed value
Generalization of "Delete subtree"
Replace subtree using template substitution
Generalization of all of the above
XSLT
Other safe languages (Java? RIF BLD?)

Impact

Most transforms are probably lossy.
Whether the loss matters depends on what you're doing.
Whether the loss is acceptable depends on what you're doing.
Each transform has a set of "impacts"
An impact has: "area" (opaque string) and "severity" (0..1)

Example Impact Handling Table

Your application has to decide how to handle impacts
Some standardization of impacts should be possible.

Scenario: Calendaring application uses RIF to support very complex scheduling rules.

Severity	Area of Impact
Severity	Soundness	Completeness	Performance	Presentation
> 0.5	Serious Error	Warning	Warning	Ignore
<= 0.5	Warning	Warning	Ignore	Ignore

Generalization of May-Ignore and Must-Understand
Addresses "who must understand"

Routing

Multiple transforms possible
Application should provide impact-cost function
XTAN pre-processor picks minimum-impact-cost transform-path
N transforms? Up to N² transforms?
20 extensions = 2²⁰ languages
(best case) XTAN only needs 20 transforms

Examples

Hello World
HTML Examples
RIF Examples
Bank Examples @@@

Example: Hello World

Input:

<a xmlns="http://www.w3.org/2008/02/xtan/test/0100-hello-world/ns">
   Hello, World
</a>

Command Line:

xtan --allowed-feature feature-b data.xml

Output:

<b xmlns="http://www.w3.org/2008/02/xtan/test/0100-hello-world/ns">
    Hello, World
</b>

Hello World Schema

Schema:

<xs:schema 
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xtan="http://www.w3.org/2008/XTAN"
  xmlns:test1="http://www.w3.org/2008/02/xtan/test/1-ns"
  targetNamespace="http://www.w3.org/2008/02/xtan/test/1-ns"
  elementFormDefault="qualified"
  version="$Id: Overview.html,v 1.33 2008/08/11 18:16:53 sandro Exp $">

  <xs:annotation>
    <xs:appinfo>

      <xtan:Transform xtan:removes="feature-a" xtan:adds="feature-b">
	<xtan:operation>
	   <xtan:GlobalElementSubstitution xtan:old="a" xtan:new="b"/>
	</xtan:operation>
      </xtan:Transform>

    </xs:appinfo>
  </xs:annotation>

  <xs:element name="a" type="xs:string">
    <xs:annotation xtan:mayIndicate="feature-a"/>
  </xs:element>
</xs:schema>

Example: blink

Input:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en-US"
      xmlns:extn="http://www.w3.org/2008/02/xtan/test/0200-blink">
  <head>
    <title>Blink Demo</title>
  </head>
  <body>
    <p><extn:blink>Blinking Text</extn:blink></p>
  </body>
</html>

Command Line:

xtan --allowed-feature b-element data.xml

Output:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en-US"
      xmlns:extn="http://www.w3.org/2008/02/xtan/test/0200-blink">
  <head>
    <title>Blink Demo</title>
  </head>
  <body>
    <p><b>Blinking Text</b></p>
  </body>
</html>

If feature "css-blink" is allowed...

Command Line:

xtan --allowed-feature css-blink data.xml

Output:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en-US"
      xmlns:extn="http://www.w3.org/2008/02/xtan/test/0200-blink">
  <head>
    <title>Blink Demo</title>
  </head>
  <body>
    <p><span style="text-decoration: blink;">Blinking Text</span></p>
  </body>
</html>

Conclusions

With XTAN, we can design our XML languages without needing to predict the future.
If languages mandate XTAN pre-processing, the system can evolve in place

Next Steps

See what RIF-WG does with this
Send me e-mail (sandro@w3.org) if you want to be on a mailing list

Some Possible Questions

When will this be a W3C Recommendation?
How's the performance?
Aren't you misusing [some XML feature]?
Why not use [some similar system]?
What if you don't have connectivity?
Does this work with RDF?
How hard is it to write those transforms?
What about security?

Forward Compatibility with XTAN

XTAN

This Talk

High Level View

My background / Semantic Web (Context)

XTAN's background / RIF (Context)

Alice and Bob (Problem Statement)

Motivating Forward Compatibility

RIF Translation Diagram

Approaches to Forward Compatibility

XTAN Sketch for <blink>

XTAN Sketch for <table>

Low Level Details

Pre-Processor

Job: transform input document into desired input language

Lookup

Features

Transforms

Impact

Example Impact Handling Table

Routing

Examples

Example: Hello World

Input:

Command Line:

Output:

Hello World Schema

Schema:

Example: blink

Input:

Command Line:

Output:

If feature "css-blink" is allowed...

Command Line:

Output:

Conclusions

Conclusions

Next Steps

Some Possible Questions