[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] updated proposed XRI 1.1 ABNF
The problem is that we want "//" to be optional in a native absolute XRI. In
other words, to satisfy our human-friendly identifier requirement, the
following should be legal native XRIs (i.e., before conversion to IRI normal
form):
=foo
@foo
xri:=foo
xri:@foo
So, if we are to follow RFC2396bis format, then we need to make "//"
optional in both XRI and absolute-XRI, then require the "//" be present when
converting to IRI normal form.
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 ]
=Drummond
-----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
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]