Title: 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:]
Sent: Thursday, August 19, 2004 2:25 PM
To:
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:]
Sent: Wednesday, August 18, 2004 4:20 PM
To: 'Dave McAlpin'; Lindelsee,
Mike ;
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:]
Sent: Wednesday, August 18, 2004 2:51 PM
To: Lindelsee, Mike ;
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:]
Sent: Wed 8/18/2004 1:13 PM
To:
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:]
Sent: Wednesday, August 18, 2004 12:58 AM
To: Lindelsee, Mike ;
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:]
Sent: Tue 8/17/2004 4:23 PM
To:
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.
