RE: [xri] * and / discussion

[Peter C Davis <peter.davis@neustar.biz>]

I personally do not see the need for explicit delagation characters
within the local-part of the address structure.  consider the case today
for http URIs:

http://www.example.com/~foo/

The DNS describes nicely the delegation of the 'authority-part' of the
address, and host-level file systems delegate further, based on local
policy.  Why should XRI's be any different.  I cannot see a reason that
an application consuming this resource (ultimately index.html... but
thats local policy too ;-)  need to understand that the '~' here meant
delegation.

If local access points services an XRI choose to delegate at the '/',
then so be it.  If clear delegation semantics are needed by a particular
usecase, cannot they simply supply cross-references instead?

Or then again, perhaps i did not eat enough wheaties this morning.

---- peterd


On Mon, 2004-06-14 at 16:47, Wachob, Gabe wrote:
> 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
> 
> 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.