OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xdi] Unifying the 3 XDI Markup Models


Thanks Drummond. 

Since I may not be available at this phone call (the time is 
from mid-night to 2am) so, I am commenting here. 

(1) The model which is presented here is actually very close to 
the one that I presented at New Orleans f2f, apart from the 
choice of tag names. I am naturally amiable to the schema, 
but I do not like the tag names, especially <instance>. 
This is terribly misleading to the object-oriented people, IMHO. 
At least, it took me a long time to grasp the intent. If we could 
devise a better tag name, that is better I think. 

(2) I am kind of vague about the use of ref and xref. I would 
appreciate if you could explain it. Actually, most people 
would require the difference of XRI/XRef/Ref, I think. 

Wow, I have to get out of the building now ( it is being closed.. 
this is not my office.) 

I will continue later. 

Nat

 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Wednesday, November 24, 2004 5:48 PM
> To: xdi@lists.oasis-open.org
> Subject: [xdi] Unifying the 3 XDI Markup Models
> 
> 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
> 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]