RE: [xri] Outline for XRI Primer

["Lindelsee, Mike " <mlindels@visa.com>]

 I came up with this order of the features by doing two things.  A
pairwise comparison between each feature and thinking about which
feature was most useful to me as an architect or developer of
distributed systems.  The other factor I considered was which features
are more clearly available in XRIs than in other URI schemes (e.g., HTTP
URLs).  For me the key is that XRIs support the development of
distributed systems and federation is something that I would argue is
necessary for those systems and not as easily available in other URI
schemes.

As for persistence falling to the bottom of my list, while I find it a
theoretically interesting feature, I don't have good use cases for it --
and XRI only supports it in syntax, not in implementation or deployment.
So given that perspective, I find all of the other features more useful
to architects/developers.

Mike

>-----Original Message-----
>From: Drummond Reed [mailto:drummond.reed@cordance.net] 
>Sent: Wednesday, February 09, 2005 5:52 PM
>To: Lindelsee, Mike ; xri@lists.oasis-open.org
>Subject: RE: [xri] Outline for XRI Primer
>
>This is great stuff for helping stamp out "tunnel vision" 
>(like I said, I've
>spent too much of my time explaining this stuff to have a fresh
>perspective).
>
>I like the idea of introducing these features first (in the 
>context of a
>high-level "Why XRI" section), then going into usage scenarios.
>
>I also fully agree with emphasizing Internationalization, I 
>just intended to
>do that in a separate section devoted to IRIs.
>
>That said, please do elaborate on why you feel Federation 
>should be the #1
>feature (and persistence the #6 feature - I find it hard to justify
>Persistence being that low.)
>
>=Drummond 
>
>-----Original Message-----
>From: Lindelsee, Mike [mailto:mlindels@visa.com] 
>Sent: Wednesday, February 09, 2005 10:34 AM
>To: xri@lists.oasis-open.org
>Subject: RE: [xri] Outline for XRI Primer
>
>While persistence might be easy to explain, I don't see it as the most
>important feature of XRIs.  I'd prefer to order the material covered in
>the primer by importance or value. In those terms, I see the 
>five listed
>features (and have added I18N to the list) as having this order (in
>order of descending value):
>
>  Federation
>  Cross References
>  Internationalization
>  Extensibility
>  Global Context Symbols
>  Persistence
>
>I also wonder if it makes sense to introduce these features first and
>then move on to the more general question of "why XRIs" followed by
>usage scenarios.
>
>Mike
>
>>-----Original Message-----
>>From: Drummond Reed [mailto:drummond.reed@cordance.net] 
>>Sent: Wednesday, February 09, 2005 9:59 AM
>>To: Wachob, Gabe; xri@lists.oasis-open.org
>>Cc: 'Fen Labalme'
>>Subject: RE: [xri] Outline for XRI Primer
>>
>>Gabe,
>>
>>Great points all. I agree that I don't think we can emphasize 
>>enough that
>>XRIs only deliver *syntactic support* for persistent 
>>identifier management.
>>The rest is up to XRI authority management policies.
>>
>>That said, let me play devil's advocate and suggest the 
>>reasons for still
>>putting it first. IMHO the first and foremost job of the 
>>Primer will be to
>>answer the questions: "Why might I want to use XRIs? What 
>>problems do they
>>help me solve that URIs alone don't? And how do they help me 
>>(an Internet
>>architect, a software developer, a network administrator, an 
>>schema/ontology
>>developer, a policy maker) solve these problems?"
>>
>>If you agree that this is the overall objective, then the 
>>reason I would
>>still suggest putting persistence first is simply that it's 
>the easiest
>>problem to explain. The need for persistent identifiers goes 
>>back almost a
>>decade, as witnessed by the entire IETF/W3C URN effort. IMHO, 
>>persistence is
>>THE killer argument for abstract identifiers. While there are 
>>solutions to
>>providing persistent network identifiers that do not involve 
>>an additional
>>layer of abstraction, using abstract identifiers is the 
>>obvious solution.
>>
>>Secondly, in the presentations I've given about XRI 
>>architecture, starting
>>with the need to use abstract identifiers for persistence 
>>leads naturally to
>>the follow-on question, "Okay, so why haven't URNs been more 
>>widely adopted?
>>What do XRIs provide that URNs didn't?" With the answer being, 
>>"A uniform
>>way to provide both a layer of persistent abstract identifiers 
>>AND a layer
>>of human-friendly, reassignable identifiers that make 
>>persistent identifier
>>layer much more useable".
>>
>>In short, the i-name --> i-number --> URI resolution pattern 
>>that has become
>>so familiar to those of us working on XRI infrastructure.
>>
>>Thirdly, I've found that leading with how XRI architecture 
>>applies to the
>>persistence problem works great as a lead-in to cross-references. IMHO
>>cross-references are the "headline" feature of XRI 
>>architecture. But I find
>>that they can also be the most challenging feature to understand. In
>>particular, if I start out trying to explain XRIs using 
>>cross-references, it
>>can be very rough going. However I've found that if I've laid 
>>out the basics
>>of how XRIs work as abstract identifiers by explaining the persistence
>>problem first, then explaining cross-references gets much easier.
>>
>>Likewise the reason I suggest placing Global Context Symbols 
>>third is that
>>GCS architecture makes a lot more sense once you understand
>>cross-references, because you understand the reasons you'd 
>>want these five
>>abstract global contexts. It also sets up nicely the other 
>>option for an XRI
>>authority, which is using a cross-reference itself as a global root.
>>
>>Once these three key concepts are in place, explaining 
>>delegation/federation
>>syntax is pretty easy, especially because you can show the 
>>usefullness of
>>delegating/federating using cross-references (e.g.,
>>"@Example.Corp*(+customer.service)".
>>
>>And with those four topics behind you, explaining XRI extensibility is
>>simply a matter of showing how these four features are 
>>combined to allow any
>>XRI authority to extend any XRI namespace.
>>
>>So that's my case for the proposed order. However as a writer, I fully
>>understand the problem of my having been steeped in XRI too 
>>long, leaving me
>>a potential victim of "tunnel vision". So if you believe 
>>there's a better
>>path we can take to explain these five features - either in a 
>different
>>order, or using a different approach altogether - let me know. 
>>I plan to
>>spend pretty much all of the week of 2/21 working on the 
>>Primer, and before
>>I start, I'd really like to have an outline everyone is 
>>comfortable with.
>>
>>=Drummond 
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_
>workgroup.php
>.
>
>
>
>