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