[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Relative XRIs
The way it is right now we're
slightly more restrictive than generic URI syntax, which I think is ok. If
we make // introduce an absolute XRI, we're in conflict with URI syntax, which
says // introduces a relative URI. Conflicting with generic syntax a) is
confusing and b) requires an odd step in transforming to IRI normal form that
I'd like to avoid.
Dave From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Wed 2/16/2005 1:35 PM To: 'Wachob, Gabe'; Dave McAlpin; xri@lists.oasis-open.org Subject: RE: [xri] Relative XRIs Gabe,
RFC 3986 allows allows a relative URI to start with "//" (they call it a "network path") but it also says that this is a "rarely used form". Because of the potential ambiguity of whether "//" would be the prefix for an absolute XRI vs. a relative XRI (if "//" was allowed at the start of a local path), I don't have a problem with not allowing the first segment of a local path to be empty (vs. all subsequent segments). But I think we should allow an absolute XRI to start with "//" and not just "xri://" as we do in the 04 working draft. My suggestion to Dave for doing this would be to simply replace "[ "xri://" ]: with "[ [ "xri:" ] "//" ]" in the current ABNF.
=Drummond
From: Wachob,
Gabe [mailto:gwachob@visa.com]
Dave- This is a surprise to me. I am pretty certain we agreed that empty segments are allowed anywhere in the path. I'll have to go back and look at the earlier drafts to see when this changed back to requiring and initial segment to be non-empty. Requiring the first segment to be non-empty for no particular reason seems really ugly when URI specifically allows it. Can we just go back to when it was allowed? -Gabe
-- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]