RE: [xri] * and / discussion

["Drummond Reed" <drummond.reed@cordance.net>]

Gabe, good points. I agree that XRI resolution is more than an application.

I also agree that having generic structure in XRIs is good, for the same
reason that it's good having it in URIs. XRI 1.0 added several generic
structure features that generic URIs don't have, and I'm not proposing
getting rid of any of any of them. What we're discussing is a change to one
of those structural features - segmentation - that is currently based on
strict hierarchy.

The 1.0 view of this feature say that strict hierarchy - slash segments
containing star or star/colon subsegments - is the best way to provide this
segmentation.

The alternate view I'm proposing is that providing two different segment
types - slash and star - may be a better way to provide this segmentation,
because it is a superset of the hierarchical view. It allows the
hierarchical view, but it doesn't impose it.

With 8 gazillion URIs deployed in the world today, there's no question that
the hiearchical view is prevalent. But from the perspective of one
particular XRI application - XDI - I believe there is a strong need to be
able to represent peer link relationships. I believe it would be ideal if
there was XDI syntax that enabled these relationships to be expressed
directly and compactly.

That's why I'm championing this proposal. However I'm wide open to ideas or
suggestions if there is another, more elegant way to address peer linking
relationships.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Monday, June 14, 2004 1:48 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] * and / discussion

Drummond-
	Comments inline..

> 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.

Two responses:

1) I don't see resolution as "an application". Its something we carefully
built our identifiers around and, quite frankly, are essential to the value
of XRIs. Resolution gets special consideration in terms of what you do with
XRIs. I believe its absolutely essential that resolution infrastructure be
widely deployed and if we are talking about resolution as merely "an
application", it takes away from the perceived value of XRI

2) I think the less structure we define for XRIs, the harder it is for folks
to build applications of XRIs since they're going to have to do more of the
parsing in the application, and less can be done at the "library" layer.
Chunking, as I'm calling it, is a *feature* of XRIs that I value. And I
assumed that XRI libraries would naturally expose the structure of XRIs in
this way. If you remove the chunking (ie nested chunking), and I have to
recreate it in an application, then it seems to me that XRIs become somewhat
less valuable. I could do that (chunking by application-specific convention)
just as easily with HTTP URLs. 

> I don't understand what you mean by the following:
> 
> "But I *still* want the ability to chunk things together beyond the
> authority - if we say / and * are peers, then the only 
> namespace-independent
> chunking syntax we have is () -- ie cross references..."
> 
> If you want segmentation ability beyond the XRI authority 
> segment, as the
> XRI author you control this completely. You can use slash 
> segments exactly
> the way you say you'd like to, and treat star segments as 
> subsegments inside
> slash segments. Another authority could do exactly the 
> opposite with their
> XRI paths. Both would be syntactically legal and interoperable.

Yes, but I might do it differnetly than the next application, and that means
writing code specifically for my application. This takes away from the value
of XRIs. 

Taking your logic to its end, why do we specify *any* structure to the right
of the first slash? 

	-Gabe