[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] updated proposed XRI 1.1 ABNF
Great work, Mike. For those who want a web version, the following page has been updated with Mike's posting: http://xrixdi.idcommons.net/moin.cgi/Xri1dot1ProposedAbnfv2 =Drummond -----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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]