RE: [xri] updated proposed XRI 1.1 ABNF

["Drummond Reed" <drummond.reed@cordance.net>]

I was thinking about this same thing this morning. Take the XRI:

	xri://(urn:isbn:1054-31-2954)/foo

Since URI scheme names (and scheme paths like URN) use colons, which are not
allowed in an URI authority segment, we'll have to escape them. So in the
conversion to IRI normal form, the above will need to become:

	xri://(urn%3Aisbn%3A1054-31-2954)/foo

If this is the case, then Dave's suggestion might be the easiest way to go:
make colons legal in all segments in XRI normal form, and require their
escaping in IRI normal form.

=Drummond 

-----Original Message-----
From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] 
Sent: Tuesday, September 28, 2004 3:26 PM
To: Lindelsee, Mike ; xri@lists.oasis-open.org
Subject: RE: [xri] updated proposed XRI 1.1 ABNF

Mike,

You do a fair amount of work to avoid ":" in authority (in xri-subseg-nc
and xri-subseg-nc-od). I think we're doing this because ":" has defined
semantics in the authority part of a URI. We don't disallow "@",
however, which also has a defined meaning for URI authorities, and we
don't disallow "@" and ":" in xrefs that appear in an XRI authority.
Consequently we have to do some escaping in authority when we go from
XRI normal form to IRI normal form to blind out "@" and ":" (along with
other characters like "/", "?" and "#" that appear in xrefs).

Since we're already allowing ":" in an XRI authority via xref, along
with several other characters that can't appear in a URI authority, I'm
wondering if we shouldn't go ahead and define authority subsegments in
terms of xri-pchar rather than xri-achar and handle ":" in the transform
to IRI normal form.

Dave

> -----Original Message-----
> From: Lindelsee, Mike [mailto:mlindels@visa.com]
> Sent: Wednesday, September 22, 2004 3:20 PM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> 
> Attached is an updated version of the 1.1 ABNF.  A number of issues
were
> raised and discussed on the editor's call yesterday.  The new ABNF
> addresses all but one of those issues.  To summarize, the issues (and
> their resolutions) were as follows.
> 
> 1.  Concern about allowing the "//" at the beginning of an XRI to be
> optional.  Resolution: "//" is never optional.  Absolute XRIs begin
with
> "xri://" or with either an xref or gcs character.
> 
> 2.  [This is the issue that is still open.]  Should multiple xrefs and
> characters be allowed to be mixed in a subsegment in the path (the
part of
> an XRI after the first "/" and before a fragment or query)?  E.g.,
> xri://@foo/(bar)abc(xyz).  The issue at stake here is should the path
be
> left as flexible and loosely-defined as possible, or should the XRI
> specification make stronger statements about the syntax and semantics
of
> segments or sub-segments in the path (and what should that syntax and
> semantics be).
> 
> 3.  Should production names that refer to sub-segments have "sub" in
their
> names or is it ok to just call them "segment" productions?
Resolution:
> replace "segment" in the appropriate productions with "subseg".
> 
> 4.  Support for authority-less XRIs.  E.g., xri:/foo.  Resolution:
Remove
> support for authority-less XRIs.
> 
> 5.  Should we follow 2396bis and disallow "[" and "]" in the query and
> fragment productions? Resolution: Follow 2396bis.
> 
> Two errors were also found in the ABNF and have been corrected.  The
first
> allowed an XRI authority that started with an xref to be followed by
> arbitrary characters (e.g., xri://(@foo)abc).  The second allowed a
> subsegment in an XRI authority to be composed of an arbitrary number
of
> characters and xrefs (e.g., xri://@foo.(@bar)abc(@xyz)def).  This
second
> error is related to issue number 2 above, but such behavior was never
> supposed to be allowed in the authority part of an XRI.
> 
> Mike


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
.