[no subject]

=Drummond 

-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com] 
Sent: Monday, August 30, 2004 2:27 PM
To: xri@lists.oasis-open.org
Subject: [xri] RE: Simplified 1.1 path syntax (was Another perspective on
GCS star issue)

While this is a good point, Drummond, it seems to me that the reason we are
trying to relax the syntax of the local part of an XRI is allow the
flexibility to support XDI.  If it were sufficient to have "!" as the
persistant delimiter and "*" as the reassignable delimiter, I would agree
with you completely.  My understanding, though, is that XDI needs more
flexibility to define additional delimiters reusing combinations of "!" and
"*".  My concern is that either XRI defines syntax and no related semantics
(in which case, why are we defining the syntax?) or we define both syntax
and semantics of local part sub-delimiters in the XRI spec and XDI then
changes those semantics.  To be concrete, in XRI terms, "/*!foo" would be
have a specific meaning.  It would literally be a null reassignable segment
followed by a persistant segment foo.  If XDI changes "*!" to mean something
else, then it breaks the meaning defined in XRI.

My goal is to give applications that use XRI (such as XDI) the flexibility
to define what they need in the local part without having to redefine
syntax/semantics already defined the XRI spec.

I truly think that to allow the most flexiblity, XRI 1.1 should define only
"/" as a segment delimiter in the local part and allow the "*" and "!"
characters, just not assign any particular meaning to them -- any meaning
will be assigned by particular applications.  Since XDI would be redefining
the semantics of delimiters in the local part anyway, I don't see it being
much overhead to also have XDI be specific about the syntax of the local
part.

As an alternative, XRI 1.1 could define syntax and semantics for "*" and "!"
as delimiters in the local part if XDI could use "*" and "!" in their
XRI-defined way (i.e., no null sub-segments that would allow "*!" etc.).
XDI could then use *different* delimiters to express the anything else that
XDI needs to express.  The xri-sub-delims lists the other characters
intended to be used this way.

Mike

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Monday, August 30, 2004 1:57 PM
> To: Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: Simplified 1.1 path syntax (was Another perspective 
> on GCS star
> issue)
> 
> 
> 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
.




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
.