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] Empty paths

Wil, great questions, see ### inline.


From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Friday, April 28, 2006 2:55 AM
To: xri@lists.oasis-open.org
Subject: [xri] Empty paths


Hi all,


While implementing the syntax parser in OpenXRI, I have stumbled upon an issue with empty paths and canonical XRIs.


Firstly, from what I read in the specs (section 2.2.5 Canonicalization), “XRI references do not have a single canonical form”. In which case, I believe that converting an XRI reference to IRI normal form should NOT muck with the optional reassignable subsegment delimiter. It also follows that we should try to preserve empty path segments as much as possible in the parser.


### Agreed. Empty path segments were explicitly allowed in the Committee Specification of XRI Syntax 2.0 in order to match the same behavior in URIs.


I am having trouble with the “correct” parser behavior when it encounters an empty path, such as xri://@foo/. When it comes to comparison, should we treat xri://@foo and xri://@foo/ as the same? What about xri://@foo/ and xri://@foo// (double slashes)?


### I think we should follow the guidance in section 6.2.3 of RFC 3986 in that regard (quoted below). It treats a single empty segment as equivalent to no empty segment, i.e., xri://@foo and xri://@foo/ are the same. However a double empty segment is NOT equivalent to a single empty segment, i.e., xri://@foo/ and xri://@foo// are NOT the same.


Hope this helps,





6.2.3.  Scheme-Based Normalization
   The syntax and semantics of URIs vary from scheme to scheme, as
   described by the defining specification for each scheme.
   Implementations may use scheme-specific rules, at further processing
   cost, to reduce the probability of false negatives.  For example,
   because the "http" scheme makes use of an authority component, has a
   default port of "80", and defines an empty path to be equivalent to
   "/", the following four URIs are equivalent:
   In general, a URI that uses the generic syntax for authority with an
   empty path should be normalized to a path of "/".  Likewise, an
   explicit ":port", for which the port is empty or the default for the
   scheme, is equivalent to one where the port and its ":" delimiter are
   elided and thus should be removed by scheme-based normalization.  For
   example, the second URI above is the normal form for the "http"





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