Simplified 1.1 path syntax (was Another perspective on GCS star issue)

["Drummond Reed" <drummond.reed@cordance.net>]

I too like the overall idea of leaving the 1.1 path as simple and flexible
as possible so that application developers can design what meets their
needs.

However, just as URI choose to define one element of path syntax "universal"
enough to be of broad use to all application developers who need it
(hierarchy syntax), I believe XRI has at least two elements of path syntax
that also meet that requirement:

1) Persistent identifier syntax
2) Cross-reference syntax

As Dave McAlpin suggested on last Thursday's XRI Editor's SC call, we can
take the same approach wrt to these two features as RFC2396bis takes to
hierarchical slash syntax, which is to say that while applications are not
required to use these XRI features in the path section, the syntax
specifided for these features is reserved to this purpose and MUST NOT be
used for another purpose.

Anyone who doesn't agree with this approach, please post to the list.

Otherwise, our action item for 1.1 is to:

1) Propose a simplified path structure in the 1.1 ABNF that supports what is
necessary for these two XRI features (as well as any others),
2) Draft the text that reserves XRI-specific syntax structures for specific
purposes.

=Drummond 

-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com] 
Sent: Thursday, August 26, 2004 3:06 PM
To: xri@lists.oasis-open.org
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.
> 
> 

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
.