RE: [xri] * and / discussion

["Wachob, Gabe" <gwachob@visa.com>]

Peter-
	I think you are responding to my "why define anything to the right of the first slash" question. I understand your response, and appreciate the approach.
	However, RFC2396 is very explicit about the concept of path separation. So while I would argue that we don't have to define the semantics of path separation, its a useful concept for building structure in an XRI beyond just seperating the ID Authority from the local party. 
	I guess at the end of the day, I don't see why we are retreating on treating '/' specially. RFC2396 treats '/' specially without defining how '/' is interpreted from scheme to scheme except by defining a (very imporant) de-relativizing algorithm. That alone is a reason not to treat '/' as some random character, or even as an equivalent character to '*'. I intend to use XRIs where URIs are specified, so I expect a generic URI parser to have some reasonable chance of success in dealing with them. Thus, '/' should be treated by us in the same way that it is treated in RFC 2396 (and -bis). 

	-Gabe
 
__________________________________________________ 
gwachob@visa.com
Chief Systems Architect
Technology Strategies and Standards
Visa International 
Phone: +1.650.432.3696   Fax: +1.650.554.6817


> -----Original Message-----
> From: Peter C Davis [mailto:peter.davis@neustar.biz]
> Sent: Monday, June 14, 2004 3:46 PM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] * and / discussion
> 
> 
> 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.
> 
> 
> 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.
>