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: FW: [xri] Another perspective on GCS star issue

Comments also inline.

----- Original Message -----
From: "Lindelsee, Mike " <mlindels@visa.com>
Date: Thursday, August 26, 2004 3:01 pm
Subject: FW: [xri] Another perspective on GCS star issue
> Comments inline.
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Wednesday, August 25, 2004 10:22 PM
> > To: xri@lists.oasis-open.org
> > Subject: [xri] Another perspective on GCS star issue
> I believe that what you are arguing for here is not really about 
> allowing null subsegments, but having a richer set of application-
> specific delimiters.  While I'm all for supporting that, I don't 
> think we need to build direct support for application-specific 
> delimiters (in the local path part of an XRI) into the XRI syntax. 
> Perhaps we should loosen our definition of the local part part of 
> the XRI to somthing as simple as:
>   local-path   =  * ( pchar / "*" / "!" / etc. )
> This would allow the most flexiblity in terms of applications 
> being able to define their own syntax/sematics on top of XRIs.

To me one of the most useful things about the URI spec is that I think 
they did not try to define everything. One of the ways I think they did 
this was to define the URI in terms of a scheme specific part. One type 
of URI, Hierarchial URIs, they specified in more detail.  What does 
everyone think  of going a similar route by specifying in detail the 
authority format and authority resolution, and saying the authority 
subsegments are followed by a local access method specific part? 

The X2R local access method can be spec'd within the XRI document, or 
even better IMHO would be to have an "X2R local access method profile 
for XRI".  This also means that developers of applications that use an 
interpretation of the local path different from X2R can just contribute 
their own profile to the XRI TC.

I'm by no means tied to the above idea, but it seems like a way to:
(1) Build in flexibility from the beginning
(2) Get past nailing down the local path specification

Bill Barnhill
Senior Consultant, Booz Allen Hamilton


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