Title: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
I like
your proposals, Dave. In principle, I agree with all of them (complete
agreement will take actually making the changes to the ABNF and looking it over
in detail). ;)
Mike
-----Original Message-----
From: Dave McAlpin
[mailto:]
Sent: Friday, August 20, 2004 12:11
PM
To: Lindelsee, Mike ;
Subject:
RE: [xri] Initial proposed XRI 1.1 ABNF and issues
analysis
Sorry I haven't tracked this closely, but glancing through the
BNF below I have a couple of comments.
1) I'd rather have
xri-sub-delims mirror the 2396bis production of sub-delims, so I'd change the
name "xri-alt-delims" to xri-sub-delims".
2) For the characters "!" and
"*", I'd prefer to move them to xri-gen-delims and represent them literally in
the productions with xri-sub-delims below, the same way "/" is represented
literally.
3) If we don't take my recommendation in 2, don't forget to
update xri-reserved to include xri-alt-delims.
4) nz-subsegment doesn't
allow foo*!bar, which I suspect you intended to allow. I think you really
wanted something like
nz-segment
= nz-sub-segment *( ( "!" / "*" ) sub-segment )
I'll try to
review the ABNF more closely in the next couple of
weeks.
Dave
-----Original Message-----
From: Lindelsee,
Mike [mailto:]
Sent: Fri
8/20/2004 12:42 PM
To:
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:]
Sent:
Thursday, August 19, 2004 11:01 PM
To: Lindelsee, Mike ;
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:]
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.
