OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis

Title: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis
It seems to me that if we drop xri-path-delim (absorb those characters back into xri-sub-delim), and include xri-auth-delim in xri-gen-delim (and correct the relevent productions), we solve Dave's first concern.  Fixing the XRI authority to support "@!"  (as well as the rest of the GCS characters) is actually really easy in a consistent way -- just add an optional xri-auth-delims after the gcs-char in the XRI-authority production (see below for the updated ABNF productions).  Changing the production would allow for "@*" as well.  While we can probably consider this as the default meaning of a single GCS character (such as "@"), I like the regularity of supporting it explicity.
The problem that I have with allowing the characters in xri-sub-delims both delimit a sub-segment and to be part of a sub-segment (by being part of xri-pchar) is that it creates an ambiguity as to what constitutes a sub-segment.  For example,  is the local path in the following xri composed of 2 or 3 sub-segments? 
According to the ABNF (if xri-sub-delims are both used in the xri-path-segment production and in the xri-pchar production), one could consider the sub-segments to be (1) a, b, and c, (2) a;b and c, or (3) a and b;c.  I'd prefer to avoid introducing the ambiguity if at all possible. 
My recommendation is to make the changes below and also exclude xri-sub-delims from the xri-pchar production.
Updated Changes to ABNF
xri-sub-delims   =  "&" / ":" / ";" / "," / "'"
xri-auth-delims  =  "!"  /  "*"
xri-gen-delims   =  "/" / "?" / "#" / "[" / "]" / "@" / "(" /
                   "(" / ")" / "$" / "+" / "=" / xri-auth-delims

xri-auth-segment =  auth-sub-segment  *( xri-auth-delims auth-sub-segment )
xri-path-segment =  path-sub-segment  *( xri-sub-delims path-sub-segment )

XRI-authority    =  ( gcs-char [xri-auth-delims] [ xri-auth-segment ] ) / xref-authority
relative-path    =  xri-path-segment * ( "/" xri-path-segment ) [ "?" xri-query ]
                                           [ "#" xri-fragment ]
xref-authority   =  xref  *( xri-auth-delims auth-sub-segment )

auth-sub-segment =  ( 1*xri-pchar /  xref )
path-sub-segment =  ( *xri-pchar / xref )

xri-pchar        =  xri-unreserved / pct-encoded / xri-sub-delims

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wednesday, August 18, 2004 4:20 PM
To: 'Dave McAlpin'; Lindelsee, Mike ; xri@lists.oasis-open.org
Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis

Agreed. Then, Dave, do you agree with Mike's suggestion of creating a new "delims" category for xri-auth-delims?


I'm beginning to wonder if the generalized treatment of subsegments in the proposed XRI 1.1 path is worth the trouble. Would it be simpler to just define * and ! as the two sub-delimins and then let the other subdelims be part of the path? That way they will be available for all producer-specific algorithms anyway


Mike, do you think it would be simpler to just have an "xri-path-delim" production for * and ! ? In that case the XRI authority segment and the path segments could go back to being the same.


Mike, one thing that occurred to me this morning: we can't eliminate null subsegments in the XRI authority segment without knocking out using ! after a GCS character (e.g., "@!1234"), as by the current BNF, ! is proceeded by a null subsegment. We'd either have to otherwise change the BNF to support that (taking us back into "decorator" land) or simply have tight resolution rules about null subsegments.




From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
Sent: Wednesday, August 18, 2004 2:51 PM
To: Lindelsee, Mike ; xri@lists.oasis-open.org
Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis


Unless there's a compelling reason to do otherwise, I'd suggest that we move "*" and "!" back to xri-gen-delims.


-----Original Message-----
From: Lindelsee, Mike  [mailto:mlindels@visa.com]
Sent: Wed 8/18/2004 1:13 PM
To: xri@lists.oasis-open.org
Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis

Do you think that we should place "*" and "!" in gen-delims then?  Or are my proposed changes ok as they stand?


-----Original Message-----
From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
Sent: Wednesday, August 18, 2004 12:58 AM
To: Lindelsee, Mike ; xri@lists.oasis-open.org
Subject: RE: [xri] Initial proposed XRI 1.1 ABNF and issues analysis

I intentionally included xri-sub-delims in xri-pchar, and this was correct in the original ABNF. Since then, someone moved sub-segment delimiters from xri-gen-delims to xri-sub-delims. I think this is just a misunderstanding of what I intended for xri-sub-delims. The idea (borrowed from 2396bis), is that xri-gen-delims are delimiters for which we define semantics and are reserved for the purpose defined in the spec. In contrast, xri-sub-delims are reserved as delimiters with no defined semantics, intended for processor specific algorithms.


-----Original Message-----
From: Lindelsee, Mike  [ mailto:mlindels@visa.com]
Sent: Tue 8/17/2004 4:23 PM
To: xri@lists.oasis-open.org
Subject: [xri] Initial proposed XRI 1.1 ABNF and issues analysis

I've taken a look at the proposed ABNF and would like to recommend a couple of changes.  First, I think we should be relatively strict in the authority part and restrict the segment delimiters to only those that are valid delimiters.  My concern is that showing other delimeters in the authority part will imply to people reading the ABNF that those delimiters might have some sort of meaning.  The second change is to remove the support for null segments in the authority part.  While there is an XDI use for null segments in the path part, it doesn't seem to be needed in the authority part.  And not allowing null segments in the authority part helps to keep resolution as simple as possible.

I also noticed what might be a bug -- the inclusion of xri-sub-delims in the xri-pchar production.  This allows segment delimiters to be embedded within segments.  I don't think that this makes sense (Dave, please correct me if I'm wrong on this).


Proposed changes to the updated XRI ABNF
(change)        xri-sub-delims  =  xri-auth-delims /  xri-path-delims
(add)           xri-auth-delims =  "!"  /  "*"
(add)           xri-path-delims =  "&" / ":" / ";" / "," / "'"

(remove)        xri-segment             =  sub-segment  *( xri-sub-delims sub-segment )
(add)           xri-auth-segment        =  auth-sub-segment  *( xri-auth-delims auth-sub-segment )
(add)           xri-path-segment        =  path-sub-segment  *( xri-sub-delims path-sub-segment )

(change)        XRI-authority   =  ( gcs-char [ xri-auth-segment ] ) / xref-authority
(change)        relative-path   =  xri-path-segment * ( "/" xri-path-segment ) [ "?" xri-query ]
                                           [ "#" xri-fragment ]
(change)        xref-authority  =  xref  *( xri-auth-delims auth-sub-segment )

(remove)        sub-segment             =  ( *xri-pchar / xref )
(add)           auth-sub-segment        =  ( 1*xri-pchar /  xref )
(add)           path-sub-segment  =  ( *xri-pchar / xref )

(change-bug)xri-pchar           =  xri-unreserved / pct-encoded

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]