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] Stable XRI 1.1 ABNF


> 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:foo@example.com) <-- absolute
./(mailto:foo@example.com) <-- 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


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