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


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 



-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Saturday, February 05, 2005 2:22 PM
To: Drummond Reed; xri@lists.oasis-open.org
Cc: Fen Labalme
Subject: RE: [xri] Outline for XRI Primer

Drummond-
	I think we have to be very careful about emphasizing the
peristence angle too much, because XRI doesn't directly provide
persistence, but rather a syntactic construct to support a
administration/resolution infrastructure that provides persistence.
Another way to put this (and you've heard this before) is that the XRI
Spec doesn't provide persistence -- the organizations providing
registration and caretaking services provide persistence. And, so while
persistent identifiers may have been a major driving factor, I don't
think its fair to say that XRI supports "persistence" out of the box any
more than your favorite URN scheme. 
	Emphasizing persistence by putting it first I think affects the
credibility of what we are saying by suggesting it's the most valuable
feature of XRI, when in fact all we are delivering is *support* for a
persistent identifier management scenario. I think the other features
are far more unique and should receive more emphasis by being placed
before persistence on the list.
	Also, while XRI doesn't deliver more than IRI does, w/r/t i18n,
I would have thought its something we'd emphasize on the feature list
since so few people are aware of IRI yet.
	Finally, as an example of XRI usage, we may also want to
consider something like Purple Numbers, a "paragraph-id" marking system
for web content developed by Eugene Eric Kim (see [1]). I think we need
some other good example besides XDI and dictionaries (though both are
great). 

	-Gabe 

[1] http://planetwork.blueoxen.net/cgi-bin/wiki.pl?PurpleNumbersAndXri

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Friday, February 04, 2005 5:17 PM
> To: xri@lists.oasis-open.org
> Cc: 'Fen Labalme'
> Subject: [xri] Outline for XRI Primer
> 
> XRI TC Members and Observers:
> 
> With the accelerating timeline and widening audience needing 
> to understand
> XRIs (especially as we go to an OASIS-wide vote), the 
> importance of the XRI
> Primer is escalating quickly.
> 
> To help move this work forward, following is a proposed 
> outline for this
> document. Please post any feedback to the list, and Fen and I 
> will work this
> into the first working draft for the XRI Editor's TC call next Friday.
> 
> =Drummond 
> 
> Introduction: Why XRIs?
> Typical Usage Scenarios
> XRI Syntax: The Five Main Features
> 	Persistence
> 	Cross References
> 	Global Context Symbols
> 	Federation
> 	Extensibility
> XRI Resolution
> 	Generic Resolution
> 	Trusted Resolution
> XRI Metadata
> 	Language
> 	Font/Glyph
> 	Versioning
> 	Datetime
> 	Annotations
> Internationalization: How XRI Builds on IRI
> XRI Applications
> 	XRI Dictionaries and XRI "Tagging"
> 	XDI (XRI Data Interchange)
> References
> 
> 
> 
> 
> 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.
> 
> 

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]