[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
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]