[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: GCS chars and star in XRI authority resolution
Drummond, I would argue that it is "@foo" that is the complication. Having "@!foo" and "@*foo" makes for very regular and simple parsing and no equivalence rules. It also gives the simplest ABNF. The problem as I see it is having a "default" that is irregular to start with.
Mike
> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Tuesday, August 24, 2004 3:48 PM
> To: Wachob, Gabe; Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: RE: [xri] RE: GCS chars and star in XRI authority resolution
>
>
> Let's discuss more on the call. I believe you are right about
> not needing
> "@foo", but that very point highlights that it would be much
> simpler for XRI
> resolution *at all levels* to only need to deal with "foo"
> and "!foo" and
> not have to add in a third option, "*foo", which adds nothing
> in terms of
> value (unless I'm missing something), yet adds considerable
> cost in terms of
> extra processing and equivalence rules.
>
> =Drummond
>
>
> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Tuesday, August 24, 2004 10:23 AM
> To: Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: RE: [xri] RE: GCS chars and star in XRI authority resolution
>
> I agree with Mike about the special treatment of "!".
>
> Also, the proposal about submitting "@foo" to the @ authority
> seems wrong to
> me. For regularity, you should be submitting "*foo". @ is
> syntactically and
> semantically separate from foo (they identify two separate
> authorities,
> among other things), so it seems odd we should submit @foo.
> 1.0 resolution
> specifies adding a . (which would now become a *) and I think
> we should
> continue to use that rule for resolution absent some
> compelling reason.
>
> -Gabe
>
>
> __________________________________________________
> gwachob@visa.com
> Chief Systems Architect
> Technology Strategies and Standards
> Visa International
> Phone: +1.650.432.3696 Fax: +1.650.554.6817
>
>
> > -----Original Message-----
> > From: Lindelsee, Mike [mailto:mlindels@visa.com]
> > Sent: Tuesday, August 24, 2004 9:58 AM
> > To: xri@lists.oasis-open.org
> > Subject: RE: [xri] RE: GCS chars and star in XRI authority
> resolution
> >
> >
> > While the ABNF is nominally simpler using the production
> > below, it makes XRIs less regular and harder to understand
> > from a human perspective. If we allow "@!", I belive that we
> > need a very strong reason not to also allow "@*".
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > Sent: Monday, August 23, 2004 5:56 PM
> > > To: Lindelsee, Mike ; xri@lists.oasis-open.org
> > > Subject: RE: [xri] RE: GCS chars and star in XRI authority
> > resolution
> > >
> > >
> > > 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
> > > .
> > >
> > >
> > >
> > >
> > > 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
.
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]