RE: [xri] updated proposed XRI 1.1 ABNF

["Lindelsee, Mike " <mlindels@visa.com>]

Good point.  I'm happy with either solution.  Following 2396 is probably preferable though.

Mike

> -----Original Message-----
> From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
> Sent: Tuesday, September 28, 2004 6:05 PM
> To: Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> 
> 
> XRI and absolute-XR are inconsistent wrt //.
> 
> XRI           = [ "xri://" ] xri-hier-part [ "?" xri-query ]
>               [ "#" xri-fragment ]
> xri-hier-part = ( xri-authority / iauthority ) [ xri-path-absolute ]
>               / ipath-empty
> absolute-XRI  = [ "xri:" ] xri-hier-part [ "?" xri-query ]
> 
> 
> One possibility is to add // to absolute-XRI, like
> 
> absolute-XRI  = [ "xri://" ] xri-hier-part [ "?" xri-query ]
> 
> 
> but my preference is to follow 2936bis.
> 
> XRI           = [ "xri:" ] xri-hier-part [ "?" xri-query ]
>               [ "#" xri-fragment ]
> xri-hier-part = "//" ( xri-authority / iauthority ) [ 
> xri-path-absolute
> ]
>               / ipath-empty
> absolute-XRI  = [ "xri:" ] xri-hier-part [ "?" xri-query ]
> 
> 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
> 
>