Unifying the 3 XDI Markup Models

["Drummond Reed" <drummond.reed@cordance.net>]

XDI TC Members and Observers,

To continue the excellent progress we had been making since the Denver f2f
on reconciling the differences between the different schema proposals, I met
in person last Thursday with Dave McAlpin and Loren West. We had a highly
productive session at which we reached what we all felt was a big
breakthrough in understanding the tension between these different
approaches.

We finally realized the conflict was rooted in different underlying
assumptions about the XDI markup model. The model Dave has been advocating
is "XML-centric", i.e., it starts from the assumption that the data is
already marked up in XML (or will be marked up in XML), so the goal is to
add XDI markup while still reusing all the existing XML markup.

The model I have been advocating is "XDI-centric", i.e., it starts from the
assumption that the raw data is going to marked up directly into XDI format,
and that data already marked up into XML format is the exception rather than
the rule.

We realized, of course, that both models are completely valid. Calling
either one "right" or "wrong" would be as silly as calling Cartesian or
radian coordinate systems "right" or "wrong". They are simply two different
models for serializing the XDI graph - one model optimized for reuse of data
and metadata in existing XML graphs, and one optimized for new XDI graphs.
Obviously for XDI to be successful, both models should be supported, i.e.,
an XDI processor should be able to understand and parse both.

We further realized that the XML-centric model has two forms, as illustrated
by Dave's examples over the past two calls. One is when the native schema is
extensible, in which case the XDI markup can be placed directly inline with
the rest of the XML elements (and every XDI element by definition describes
its parent element). The other is when the schema for the native XML
document is not extensible, so the XML needs to be "wrapped" in an XDI
envelope. 

For easy reference, we labelled these three different XDI markup models as
follows:

1) "Inline" or "Direct" is when the XDI markup is placed directly into an
XML instance document whose schema(s) are extensible. The root element of
this XML document does not change. This mode will typically be preferred for
XDI adaptation/enhancement of XML-centric applications that have been
designed or can be easily modified to use extensible XML schemas.

2) "Enveloped" or "Wrapped" is when the XDI markup is wrapped around a
single XML instance document because the native XML schema is not directly
extensible. In this case the root element of the outer wrapper is from the
XDI schema (specifically, the "XDI-XML" element in the v1 unified schema
proposal), but the native XML document inside the wrapper stays intact. This
mode will be typically be preferred for XDI adaptation/enhancement of
XML-centric applications that do not use extensible schemas.

3) "Open" or "Nested" applies to an XDI document for which the root element
is the XDI Resource element, and which therefore allows any number of nested
Resources. This mode will be typically be preferred for XDI dictionaries,
XDI-centric applications, or even large distributed XML applications whose
primary challenge is needing to share data across a large number of
different XML schemas.

In cooking on this after our session, it became apparent that it would be a
tremendous virtue to make all 3 models interoperable. In other words, the
Open model should be able to contain instances of either the Enveloped or
Inline models, and the Enveloped model should be able to contain an instance
of the Inline model (for cases where parts of an XML schema are extensible
and parts are not.)

So it became very attractive to develop a single unified XDI schema that
supports all three models. This turns out to be relatively easy because the
majority of the schema describes the Open model (since that's where XDI
itself describes the document structure), while a single element, "XDI-XML",
provides the "switchover point" from the XDI-centric model to the
XML-centric model.

Once inside the XDI-XML element, the only structure needed is an "XMLMeta"
element and an "XMLData" element to support the Enveloped model. This is
because the Inline model doesn't need any other elements - it will just
reuse elements from the XDI schema or from other extensions written for the
"XMLMeta" element (see below).

Lastly, I added an "XRI-XML" element to support basic XDI addressing inside
either the XMLMeta element for the Enveloped model or anywhere in the Inline
model. The full The v1 unified schema proposal has been uploaded to:
http://www.oasis-open.org/committees/download.php/10237/draft-xdi-unified-sc
hema-v1.xsd. 

Another beauty of this approach is that it provides two clear paths for
extending XDI vocabulary - one XML-centric and one XDI-centric:

1) The XML-centric option is to write a new XML schema defining a new
element for use inside the XMLMeta element, per the SOAP model we have been
discussing for some time.
2) The XDI-centric option is to add a new XDI resource to an XDI dictionary,
then use it in the Open model to describe other resources.

Both would be equally valid ways of extending XDI, depending on your
requirements, and both would be understood by XDI processors.

Obviously this will be the main topic of our call tomorrow. To help ground
the discussion, I have uploaded three example documents:

1) A third version of a short-form XDI business card using the v1 unified
schema (very few changes from the previous version):
http://www.oasis-open.org/committees/download.php/10238/draft-example-bizcar
d-short-v3.xml

2) A third version of the long-form (including all references) XDI business
card also using the v1 unified schema (again, very few changes from the
previous version):
http://www.oasis-open.org/committees/download.php/10239/draft-example-bizcar
d-long-v3.xml

3) Finally, a second version of Dave's original XML document markup example,
now using the v1 unified schema. Note that this is just an adaptation of his
original example, so he, Loren, and others may have many different ideas of
how XDI-XML should work:
http://www.oasis-open.org/committees/download.php/10240/draft-example-XDI-XM
L-v2.xml 

=Drummond