Comments also inline.
----- Original Message -----
From: "Lindelsee, Mike " <>
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:]
> > Sent: Wednesday, August 25, 2004 10:22 PM
> > To:
> > 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
