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


I like your thinking, Bill.  Leaving XRI extremely flexible and making it clear that applications that use XRI (such as XDI) need to specify the syntax of the local path and the local resolution around it makes a lot of sense to me.

Is our effort to bring the ABNF in line with the productions of 2396bis and IRI going too far with respect to the local path?  Unless we *need* the syntax specified and the underlying semantics, perhaps it would be better to just allow the appropriate characters in any combination.

Mike

> -----Original Message-----
> From: Barnhill William [mailto:barnhill_william@bah.com]
> Sent: Thursday, August 26, 2004 1:18 PM
> To: xri@lists.oasis-open.org
> 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
> 
> 
> 
> 
>  
>  
> 
> 
> 
> 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.
> 
> 


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