[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
>
> ----- Original Message -----
> From: "Lindelsee, Mike " <mlindels@visa.com>
> Date: Friday, August 20, 2004 12:42 pm
> Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
>
> > Good point. Your changes work for me.
> >
> > Mike
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Thursday, August 19, 2004 11:01 PM
> > To: Lindelsee, Mike ; xri@lists.oasis-open.org
> > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
> >
> >
> >
> > Problem: this last BNF would not allow xri-auth-delims (! and *)
> > in a path segment.
> >
> >
> >
> > I'm thinking that while the initial proposal to generalize the
> > subsegment delimiters was intended to make things simpler, the
> > problem Mike pointed out actually makes it more complex than
> > another approach: putting just two delimiters (! and *) into "xri-
> > sub-delims", then putting all the rest of the URI sub-delims into
> > a new "xri-alt-delims". Now xri-pchar can include xri-alt-delims
> > just like URI pchar includes URI sub-delims in RFC2396bis.
> >
> >
> >
> >
> > So we'd have:
> >
> >
> >
> > xri-gen-delims = "/" / "?" / "#" / "[" / "]" / "@" / "(" /
> >
> > ")" / "$" / "+" / "="
> > xri-sub-delims = "!" / "*"
> >
> > xri-alt-delims = "&" / ":" / ";" / "," / "'"
> >
> > xri-pchar = xri-unreserved / pct-encoded / xri-alt-delims
> >
> >
> >
> > sub-segment = ( *xri-pchar / xref )
> > nz-sub-segment = ( 1*xri-pchar / xref )
> >
> >
> >
> > xri-segment = sub-segment *( xri-sub-delims sub-segment )
> > nz-segment = nz-sub-segment *( xri-sub-delims nz-sub-
> > segment )
> >
> > XRI-authority = ( gcs-char [xri-sub-delims] [ nz-segment ] ) /
> > xref-authority
> > relative-path = xri-segment * ( "/" xri-segment ) [ "?" xri-
> > query ]
> > [ "#" xri-fragment ]
> > xref-authority = xref *( xri-sub-delims nz-sub-segment )
> >
> >
> >
> >
> >
> > =Drummond
> >
> >
> >
> >
> > _____
> >
> >
> > From: Lindelsee, Mike [mailto:mlindels@visa.com]
> > Sent: Thursday, August 19, 2004 2:25 PM
> > To: xri@lists.oasis-open.org
> > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
> >
> >
> >
> > It seems to me that if we drop xri-path-delim (absorb those
> > characters back into xri-sub-delim), and include xri-auth-delim in
> > xri-gen-delim (and correct the relevent productions), we solve
> > Dave's first concern. Fixing the XRI authority to support "@!"
> > (as well as the rest of the GCS characters) is actually really
> > easy in a consistent way -- just add an optional xri-auth-delims
> > after the gcs-char in the XRI-authority production (see below for
> > the updated ABNF productions). Changing the production would
> > allow for "@*" as well. While we can probably consider this as
> > the default meaning of a single GCS character (such as "@"), I
> > like the regularity of supporting it explicity.
> >
> >
> >
> > The problem that I have with allowing the characters in xri-sub-
> > delims both delimit a sub-segment and to be part of a sub-segment
> > (by being part of xri-pchar) is that it creates an ambiguity as to
> > what constitutes a sub-segment. For example, is the local path
> > in the following xri composed of 2 or 3 sub-segments?
> >
> >
> >
> > xri://@corp/a;b;c
> >
> >
> >
> > According to the ABNF (if xri-sub-delims are both used in the xri-
> > path-segment production and in the xri-pchar production), one
> > could consider the sub-segments to be (1) a, b, and c, (2) a;b and
> > c, or (3) a and b;c. I'd prefer to avoid introducing the
> > ambiguity if at all possible.
> >
> >
> >
> > My recommendation is to make the changes below and also exclude
> > xri-sub-delims from the xri-pchar production.
> >
> >
> >
> > Mike
> >
> >
> >
> > Updated Changes to ABNF
> >
> > ---------------------------------------
> >
> >
> >
> > xri-sub-delims = "&" / ":" / ";" / "," / "'"
> > xri-auth-delims = "!" / "*"
> >
> > xri-gen-delims = "/" / "?" / "#" / "[" / "]" / "@" / "(" /
> >
> > "(" / ")" / "$" / "+" / "=" / xri-auth-delims
> >
> > xri-auth-segment = auth-sub-segment *( xri-auth-delims auth-sub-
> > segment )
> > xri-path-segment = path-sub-segment *( xri-sub-delims path-sub-
> > segment )
> >
> > XRI-authority = ( gcs-char [xri-auth-delims] [ xri-auth-
> > segment ] ) / xref-authority
> > relative-path = xri-path-segment * ( "/" xri-path-segment ) [
> > "?" xri-query ]
> > [ "#" xri-fragment ]
> > xref-authority = xref *( xri-auth-delims auth-sub-segment )
> >
> > auth-sub-segment = ( 1*xri-pchar / xref )
> > path-sub-segment = ( *xri-pchar / xref )
> >
> > xri-pchar = xri-unreserved / pct-encoded / xri-sub-delims
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Wednesday, August 18, 2004 4:20 PM
> > To: 'Dave McAlpin'; Lindelsee, Mike ; xri@lists.oasis-open.org
> > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
> >
> > Agreed. Then, Dave, do you agree with Mike's suggestion of
> > creating a new "delims" category for xri-auth-delims?
> >
> >
> >
> > I'm beginning to wonder if the generalized treatment of
> > subsegments in the proposed XRI 1.1 path is worth the trouble.
> > Would it be simpler to just define * and ! as the two sub-delimins
> > and then let the other subdelims be part of the path? That way
> > they will be available for all producer-specific algorithms anyway
> >
> >
> >
> > Mike, do you think it would be simpler to just have an "xri-path-
> > delim" production for * and ! ? In that case the XRI authority
> > segment and the path segments could go back to being the same.
> >
> >
> >
> > Mike, one thing that occurred to me this morning: we can't
> > eliminate null subsegments in the XRI authority segment without
> > knocking out using ! after a GCS character (e.g., "@!1234"), as by
> > the current BNF, ! is proceeded by a null subsegment. We'd either
> > have to otherwise change the BNF to support that (taking us back
> > into "decorator" land) or simply have tight resolution rules about
> > null subsegments.
> >
> >
> >
> > =Drummond
> >
> >
> >
> >
> > _____
> >
> >
> > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
> > Sent: Wednesday, August 18, 2004 2:51 PM
> > To: Lindelsee, Mike ; xri@lists.oasis-open.org
> > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
> >
> >
> >
> > Unless there's a compelling reason to do otherwise, I'd suggest
> > that we move "*" and "!" back to xri-gen-delims.
> >
> > Dave
> >
> >
> > -----Original Message-----
> > From: Lindelsee, Mike [ mailto:mlindels@visa.com]
> > Sent: Wed 8/18/2004 1:13 PM
> > To: xri@lists.oasis-open.org
> > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
> >
> > Do you think that we should place "*" and "!" in gen-delims then?
> > Or are my proposed changes ok as they stand?
> >
> > Mike
> >
> > -----Original Message-----
> > From: Dave McAlpin [ mailto:Dave.McAlpin@epok.net]
> > Sent: Wednesday, August 18, 2004 12:58 AM
> > To: Lindelsee, Mike ; xri@lists.oasis-open.org
> > Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
> >
> >
> >
> > I intentionally included xri-sub-delims in xri-pchar, and this was
> > correct in the original ABNF. Since then, someone moved sub-
> > segment delimiters from xri-gen-delims to xri-sub-delims. I think
> > this is just a misunderstanding of what I intended for xri-sub-
> > delims. The idea (borrowed from 2396bis), is that xri-gen-delims
> > are delimiters for which we define semantics and are reserved for
> > the purpose defined in the spec. In contrast, xri-sub-delims are
> > reserved as delimiters with no defined semantics, intended for
> > processor specific algorithms.
> >
> > Dave
> >
> >
> > -----Original Message-----
> > From: Lindelsee, Mike [ mailto:mlindels@visa.com]
> > Sent: Tue 8/17/2004 4:23 PM
> > To: xri@lists.oasis-open.org
> > Subject: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
> >
> > I've taken a look at the proposed ABNF and would like to recommend
> > a couple of changes. First, I think we should be relatively
> > strict in the authority part and restrict the segment delimiters
> > to only those that are valid delimiters. My concern is that
> > showing other delimeters in the authority part will imply to
> > people reading the ABNF that those delimiters might have some sort
> > of meaning. The second change is to remove the support for null
> > segments in the authority part. While there is an XDI use for
> > null segments in the path part, it doesn't seem to be needed in
> > the authority part. And not allowing null segments in the
> > authority part helps to keep resolution as simple as possible.
> >
> > I also noticed what might be a bug -- the inclusion of xri-sub-
> > delims in the xri-pchar production. This allows segment
> > delimiters to be embedded within segments. I don't think that
> > this makes sense (Dave, please correct me if I'm wrong on this).
> >
> > Mike
> >
> >
> > Proposed changes to the updated XRI ABNF
> > ----------------------------------------
> > (change) xri-sub-delims = xri-auth-delims /
> xri-path-delims
> > (add) xri-auth-delims = "!" / "*"
> > (add) xri-path-delims = "&" / ":" / ";" / "," / "'"
> >
> > (remove) xri-segment = sub-segment *( xri-sub-
> > delims sub-segment )
> > (add) xri-auth-segment = auth-sub-segment *(
> > xri-auth-delims auth-sub-segment )
> > (add) xri-path-segment = path-sub-segment *(
> > xri-sub-delims path-sub-segment )
> >
> > (change) XRI-authority = ( gcs-char [ xri-auth-segment ]
> > ) / xref-authority
> > (change) relative-path = xri-path-segment * ( "/" xri-
> > path-segment ) [ "?" xri-query ]
> > [ "#" xri-fragment ]
> > (change) xref-authority = xref *( xri-auth-delims auth-
> > sub-segment )
> >
> > (remove) sub-segment = ( *xri-pchar / xref )
> > (add) auth-sub-segment = ( 1*xri-pchar / xref )
> > (add) path-sub-segment = ( *xri-pchar / xref )
> >
> > (change-bug)xri-pchar = xri-unreserved / pct-encoded
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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]