[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]