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: XRIs and paths to XDI resources


[Note: I'm extending a thread started on the XRI TC on '/' & '*' syntax to
include proposed XDI addressing requirements that bear on this thread, so
I'm sending this message to both lists. =Drummond]

To address Loren's final question in his message below: "Could you explain
what's broken in XRI, and why it shouldn't be fixed using a more familiar
approach?"

I wouldn't say anything is "broken" in XRIs (with the exception of the dot
name problem we're fixing.) What I'd say is that something is "missing", and
that something is the ability to represent cross-hierarchy, peer-link
relationships between resources as easily as XRIs and URIs let you represent
hierarchical relationships between resources today.

As to the importance of this requirement, let me propose two fundamental XDI
addressing requirements:

1) Any node in the XDI graph (i.e., any node of any XDI document) must be
uniquely addressable with at least one XRI.

2) Any PATH to any node in the XDI graph must be expressable with at least
one XRI.

I believe the latter requirement is necessary in order to enable (not
require, but enable):

a) Addressing of data by reference rather by value (i.e., being able to
express both aggregation and composition relationships between resources).
b) Addressing of cached data.
c) Expression of data sharing rights.

I'm working on sample XDI documents and accompanying XRIs that illustrate
these requirements in action; I'll upload as soon as they are ready.

=Drummond 

-----Original Message-----
From: Loren West [mailto:loren.west@epok.net] 
Sent: Monday, June 14, 2004 2:31 PM
To: 'Drummond Reed'; xri@lists.oasis-open.org
Subject: RE: [xri] * and / discussion

> Drummond says:
> 
> In terms of "chunking", or more technically, "segmentation", it seems like
> there are two approaches we can take.
> 
> 1) Keep the current 1.0 segmentation hierarchy, i.e., divide XRIs into
slash
> segments first, then divide slash segments into star subsegments (or star
> and colon subsegments).
> 
> 2) Or, as I'm arguing, make it even simpler by just defining two syntactic
> segment types - slash segments and star segments - and then let XRI
> applications use them as they wish. In this approach, XRI resolution would
> be one such application, and that application would define star segments
> before the first slash to be authority delegation.

I fail to see how #2 is simpler.  Everyone understands segments
and sub-segments in URIs, and that concept works well within XRIs
(and URI translated XRIs).

It's a single hierarchy model.

You're suggesting there be multiple hierarchies built into the
identifier itself - that it represents a "web" of information.

It is a novel concept, but I argue that you're trying to do too
much with the identifier.

Could you explain what's broken in XRI, and why it shouldn't be
fixed using a more familiar approach?

=Loren




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]