> 5. The ABNF explicitly disallows cross references as the
> first segment of a
> relative XRI. This is due to allowing "xri://" to be
> optional. From our
> perspective, it seems broken to disallow this whole class
> of XRI's. For instance,
> xri://@foo/(+SecurityPolicy) is allowed by the ABNF but
> the relative XRI
> "(+SecurityPolicy)" is always treated as an absolute and
> therefore can never
> be expressed in a relative form. Anyway, our
> recommendation is that we should
> either require "xri://" in all absolute XRI's or take
> another careful look
> at what we are doing to the XRI syntax to accomodate
> "xri://" being optional.
Drummond and I discussed issue 5 and the resolution we both agreed upon was that relative XRI's that start with a cross reference are distinguished from absolute XRI's that start with a cross reference through the use of "./" . That is:
(mailto:) <-- absolute
./(mailto:) <-- relative
This use of ./ has a precedent. We note that ./ is required when you have a relative XRI (or URI for that matter) where the first segment has a ":". For example, the relative XRI "foo:22/bar" is easily confused for a absolute URI of the scheme "foo" if you don't use "./foo:22/bar"
./ is legal syntax to begin an XRI with in the new BNF. We'll have to have language describing the use of ./ for this new disambiguation and it probably will affect normalization/comparison rules as well (maybe not).
-Gabe
