RE: [xri] updated proposed XRI 1.1 ABNF

["Wachob, Gabe" <gwachob@visa.com>]

I think the point is that we follow 2396bis by virtue of escaping and that if we are bneing over backwards to escape in XRI Normal form, then its really not worth it. We will always conform to 2396bis post-normalization (ie post-transform to IRI-normal form)

	-Gabe

 
__________________________________________________ 
gwachob@visa.com
Chief Systems Architect
Technology Strategies and Standards
Visa International 
Phone: +1.650.432.3696   Fax: +1.650.554.6817


> -----Original Message-----
> From: Lindelsee, Mike [mailto:mlindels@visa.com]
> Sent: Wednesday, September 29, 2004 8:41 AM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] updated proposed XRI 1.1 ABNF
> 
> 
> 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
> > 
> > 
> 
> 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.