RE: [xri] RE: GCS chars and star in XRI authority resolution

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

In retrospect I believe we erred in the 1.0 BNF in allowing what was then
dot (and is now star) after a GCS character. I believe a cleaner approach in
XRI 1.1 would be the following rationale: 

1) All the GCS chars except "!" are "proxies" for "*", in that they default
to a reassignable subsegment. 

2) Therefore, there is no need for * following a GCS character. It is
redundant - the equivalent of "**", which makes no sense.

3) Therefore the simplest rule, which eliminates any confusion and any
chance of false negatives in a equivalence comparision, is 

GCS-authority    =  gcs-char [ "!" ] [ nz-segment ]

Also, to keep XRI resolution consistent, the GCS char would be treated
exactly the same as star in subsegment resolution, i.e., it would be
submitted as part of the string being resolved when resolving against a GCS
root. For example, when resolving "@foo*bar", the string submitted to the
"@" authority would be "@foo", and the string submitted to the "@foo"
authority would be "*bar".

=Drummond 


-----Original Message-----
From: Lindelsee, Mike [mailto:mlindels@visa.com] 
Sent: Monday, August 23, 2004 3:57 PM
To: xri@lists.oasis-open.org
Subject: [xri] RE: GCS chars and star in XRI authority resolution

My preference would be to stick to a completely regular syntax.  I.e.,
always prefix the sub-segment that follows the GCS char with a "*" or a "!",
but I realize that this won't be satisfactory for many others, so I think we
should stick with xri 1.0 rules/syntax wrt this issue and allow any of:

   xri:@foo
   xri:@!foo
   xri:@*foo

where xri:@foo is equivalent to xri:@*foo.

Mike

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Friday, August 20, 2004 3:15 PM
> To: Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: GCS chars and star in XRI authority resolution
> 
> 
> Per the question Mike raises: "The inclusion (or not) of the 
> delimiter that
> indicates reassignability or persistence in the sub-segment that gets
> resolved is something that we'll still need to discuss as we revisit
> resolution for 1.1."
> 
> I'd like to propose something I think will make both 
> equivalence and XRI
> authority resolution simpler in 1.1.
> 
> Per the BNF I just posted following Dave's suggestion, a GCS-rooted
> authority segment would be:
> 
> GCS-authority    =  gcs-char [ "!" / "*" ] [ nz-segment ]
> 
> Therefore a GCS char can be followed by either an nz-segment, 
> or !, or *. So
> the following are all legal:
> 
> @foo
> @*foo
> @!foo
> 
> In XRI 1.0 we treated "@foo" and "@*foo" as equivalent. We 
> said the * was
> "assumed" with any GCS char. 
> 
> In XRI 1.1 I'd propose that we simplify things in one of two ways:
> 
> OPTION 1: BY NOT DEFINING GCS-CHAR AND GCS-CHAR* AS EQUIVALENT
> 
> Instead, the rules would be that:
> 
> 1) By default, the nz-segment following a GCS char is reassignable.
> 2) In XRI authority resolution, if EITHER ! or * preceed an 
> nz-sub-segment,
> they are treated as part of the nz-sub-segment from the standpoint of
> resolution, i.e., are part of the value being resolved.
> 
> By these rules, @foo, @*foo, and @!foo are all different 
> values. "foo" is a
> reassignable sub-segment in both "@foo" and "@*foo" by definition, but
> "@foo" and "@*foo" are not equivalent.
> 
> OPTION 2: BY NOT ALLOWING * DIRECTLY AFTER A GCS CHAR
> 
> In ths option, the BNF would be:
> 
> GCS-authority    =  gcs-char [ "!" ] [ nz-segment ]
> 
> Again, the same two rules proposed in Option 1 would apply. 
> Only now you can
> just have "@foo" and "@!foo", because "@*foo" is illegal.
> 
> I believe this is actually the option most consistent with 
> the rule that by
> default, the nz-sub-segment following a GCS char is 
> reassignable, because it
> means that the * is already inherent in the GCS char, just 
> the way it is
> inherent in a slash (reassignable sub-segment being the default after
> slash).
> 
> Which do folks prefer?
> 
> =Drummond 
> 
> 
> -----Original Message-----
> From: Lindelsee, Mike [mailto:mlindels@visa.com] 
> Sent: Friday, August 20, 2004 2:10 PM
> To: xri@lists.oasis-open.org
> Subject: RE: RE: [xri] Initial proposed XRI 1.1 ABNF and 
> issues analysis
> 
> Bill,
> 
> I'm not clear which XRI ABNF you are asking your questions 
> with respect to.
> I don't believe that the XRI below (xri:@example*:23:45) 
> would be valid
> using XRI 1.0 syntax ('*' is only allowed as a GCS character 
> in 1.0).  The
> XRI also wouldn't be valid in the original 1.1 ABNF ('*' and ':' can't
> follow one another). It would be valid in the various 
> iterations of the ABNF
> that Dave, Drummond and I have been discussing on the list -- 
> though the
> interpretation of the sub-segments might be slightly 
> different between the
> various iterations.
> 
> The latest proposal would break the XRI up as follows:
> 
> 1:  @
> 2:  *example   (reassignable sub-segment - and showing 
> implicit delimiter)
> 3:  *:23:45    (reassignable sub-segment)
> 
> The inclusion (or not) of the delimiter that indicates 
> reassignability or
> persistence in the sub-segment that gets resolved is 
> something that we'll
> still need to discuss as we revisit resolution for 1.1.
> 
> Mike
> 
> > -----Original Message-----
> > From: Barnhill William [mailto:barnhill_william@bah.com]
> > Sent: Friday, August 20, 2004 11:03 AM
> > To: Lindelsee, Mike 
> > Cc: xri@lists.oasis-open.org
> > Subject: Re: RE: [xri] Initial proposed XRI 1.1 ABNF and 
> > issues analysis
> > 
> > 
> > Looks good to me as well, but some questions...
> > (1) Is this XRI valid? xri:@example*:23:45
> > (2) If valid, would it represent 4 resolution steps:
> > 1:   @
> > 2:     .example
> > 3:        *:23
> > 4:           *:45
> > With the '. on 1: and the '*' on 4 being implicitly stated.
> > 
> > (3) If the above XRI is suppose to respresent 4 resolution 
> > steps do not 
> > the new rules result in only 3 steps? As :23:45 would be 
> > considered one 
> > segment.
> > 
> > Thanks,
> > 
> > Bill Barnhill
> > 
> 
> 
> 

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
.