3 key XDI metaschema issues

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

XDI TC Members and Observers:

I hate posting this late the night before a TC call, but that's the kind of
week it's been. Besides, we're not going to settle all the issues regarding
the XDI metaschema on tomorrow's call anyway, so this email is just to
complete my action item from the f2f, which was to: a) post the XSD format
of the of proposed XDI metaschema I presented on at the f2f (see the link
below), and b) analyze and explaining the key differences between it and the
XDI object model Nat presented.

In my analysis, there are 3 key differences, listed below in order from most
minor to most major:

1) SEPARATE ELEMENTS FOR E-NAMES AND E-NUMBERS

In the proposed XSD, there is a single element <xri> for all XRI values. In
Nat's object model, this is broken into separate elements for reassignable
XRIs (e-names) and persistent XRIs (e-numbers).

PROS
* May be more efficient for parsing/indexing of reassignable vs. persistent
XRI values for an XDI graph node

CONS
* A single XRI element makes it easy to apply the schema rule "1 or more"
XRI values of any kind (this makes the node XRI-addressable). If there are
separate elements, this rule doesn't work. Even though it might be best
practices for all nodes to have at least one e-number, there are use cases
where they won't.
* The distinction between e-name and e-number values is already present in
the proposed metaschema in that all persistent XRI values would begin with
either =:, @:, +:, or :.
* Adds an additional element, introducing additional complexity into the XDI
graph.

2) ADDITION OF A TYPE ELEMENT

In the proposed XSD, there is no separate element for indicating the type of
a Resource or a Link. It was assumed that this type of metadata would be
provided using the same mechanism as all other XDI metadata, namely by a
resource specified XDI Service Dictionary for typing, e.g., "$type". Nat's
object model proposes an XML element ("Type") to do this directly, which
would take an XRI as its value.

PROS
* More efficient parsing of type metadata by implementations, as the tree of
Resource metadata does not need to be crawled to discover the type of a
Resource.

CONS
* Introduces a separate model for representing type metadata than all other
forms of XDI metadata.
* Can be prone to the "type abstraction" problem, i.e., how do you represent
a resource that is itself a Type? (This will be very common in XDI data
definitions.)
* Adds an additional element, introducing additional complexity into the XDI
graph.

3) LINK AS AN ELEMENT OF RESOURCE

In the proposed XSD, there are separate elements for Resource and Link,
however except for the tag, their element definitions are identical. In
Nat's object model, Link becomes a subelement of Resource, so you know a
Resource is a link if the Link element is present.

PROS
* More efficient object model, since all objects are Resources.

CONS
* A Resource tree must be traversed in order to determine if it is a Link.
* Introduces the problem of addressing Resources (data for which an
authority is authoritative) vs. Links (data which is cached from another
authority). The address of the Link already uniquely identifies the XDI node
(since a node can only have one Link to another node), however a Resource
can also have its own XRI. So if they are combined, are you addressing the
Resource or the Link? The proposed metaschema addressing mechanism makes
this distinction syntactically precise.

-----------

That's my analysis so far. Nat, please add your own views and comments. As
we agreed at the f2f, ultimately we need to converge onto one XSD, so this
is a step in that direction.

We'll discuss in detail on the call tomorrow.

=Drummond 



-----Original Message-----
From: drummond.reed@cordance.net [mailto:drummond.reed@cordance.net] 
Sent: Tuesday, May 11, 2004 9:41 PM
To: xdi@lists.oasis-open.org
Subject: [xdi] Groups - draft-xdi-metaschema-v1.txt uploaded

The document draft-xdi-metaschema-v1.txt has been submitted by Drummond Reed
(drummond.reed@cordance.net) to the OASIS XRI Data Interchange (XDI) TC
document repository.

Document Description:
Initial proposed XDI metaschema (from XDI whitepaper v2) in XSD format - for
discussion on 5/12 telecon.

Download Document:  
http://www.oasis-open.org/apps/org/workgroup/xdi/download.php/6719/draft-xdi
-metaschema-v1.txt

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/xdi/document.php?document_id=67
19


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.