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


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