[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]