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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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