Wil, does that mean you are or are not in favor of the proposed solution at
the end of this message (i.e., the rules that add a leading forward slash if
one is not present in the <xrd:Path> element)?
Those rules don't actually take any position on whether @example normalizes
to @example/ or not. They just recognize the reality that IF there is a
non-null Path String, it must be delimited from the Authority String by a
forward slash (and if the Path String is null, it can match either @example
or @example/).
=Drummond
> -----Original Message-----
> From: Tan, William [mailto:]
> Sent: Tuesday, October 23, 2007 3:21 PM
> To: Drummond Reed
> Cc: 'Gabe Wachob'; 'OASIS XRI TC'
> Subject: Re: [xri] ED07 Issue #2: Leading Slash in Path Element
>
> Is this the particular sentence that you are referring to?
>
> RFC3986 Section 6.2.3:
>
> In general, a URI that uses the generic syntax for authority with an
> empty path should be normalized to a path of "/".
>
>
> If that's the case, I guess I still take issue with us following it
> religiously. For one, the "should" in that sentence is not uppercase.
> Secondly, the last sentence in that section says "Other scheme-specific
> normalizations are possible." Thirdly, if @example can be normalized to
> @example/ then we can expect to see it popping up everywhere like
> browser address bars.
>
> =wil
>
> Drummond Reed wrote:
> >
> > Yes, that's right. I think it solves the issue without introducing any
> > backwards-compatability issues with XRDs in the wild.
> >
> > =Drummond
> >
> > ------------------------------------------------------------------------
> >
> > *From:* Gabe Wachob [mailto:]
> > *Sent:* Tuesday, October 23, 2007 2:12 PM
> > *To:* 'Drummond Reed'; 'OASIS XRI TC'
> > *Subject:* RE: [xri] ED07 Issue #2: Leading Slash in Path Element
> >
> > You're basically saying that a forward slash is assumed in the path
> > part of the query, and in the XRD Path element, with the further
> > proviso that an empty XRD Path element is also equals to one with a
> > forward slash.
> >
> > This is basically in alignment with the comparison rules from 3986, I
> > believe. Wil?
> >
> > -Gabe
> >
> > ------------------------------------------------------------------------
> >
> > *From:* Drummond Reed [mailto:]
> > *Sent:* Tuesday, October 23, 2007 2:02 PM
> > *To:* 'OASIS XRI TC'
> > *Subject:* [xri] ED07 Issue #2: Leading Slash in Path Element
> >
> > In his feedback on ED06, Gabe noted that the rule in the Path matching
> > (section 12.3.7 of ED06) about removing the forward slash is "odd and
> > creates odd-looking scenarios in the example table. What's the reason?"
> >
> > To this, Wil responded yesterday:
> >
> > I remember bringing this up several times before, but memory is
> > failing me why we do it.
> >
> > I think we are doing it for backward compatibility with WD10, which
> > doesn't have the leading slash in the Path element content (presumably
> > for user-friendliness.)
> >
> > I agree with Gabe that the brain has to work harder to see an
> > invisible slash in the Path content of the second column (XRD Path
> > Element). It would be much easier to compare column 1 and 2 without
> > having to perform that extra mental step. That said, a lot of the
> > scenarios are probably too obscure to be used. However, XDI might have
> > different requirements.
> >
> > ************
> >
> > Following appear to be our two choices with regard to leading forward
> > slashes in Path matching:
> >
> > OPTION #1: Stay with ED06 and specify that the forward slash that
> > separates the QXRI Path String from the QXRI Authority String is NOT
> > included in the <xrd:Path> element.
> >
> > OPTION #2: Change to specifying that the forward slash that separates
> > the QXRI Path String from the QXRI Authority String SHOULD be included
> > in the <xrd:Path> element, and then define handling of the two special
> > cases when:
> >
> > A) The <xrd:Path> element is empty
> >
> > B) The <xrd:Path> element does not begin with a forward slash.
> >
> > ************
> >
> > PROPOSED SOLUTION:
> >
> > Go with option #2, i.e., and add the following two rules:
> >
> > 1) If the <xrd:Path> element is empty, it is a match for an empty Path
> > String either WITH or WITHOUT a leading forward slash.
> >
> > 2) If the <xrd:Path> element does not begin with a forward slash, a
> > SINGLE FORWARD SLASH is ASSUMED. This will provide backwards
> > compatability with all XRDs in the wild.
> >
> > 3) If the <xrd:Path> element DOES begin with a forward slash, then all
> > forward slashes are signficant.
> >
> > These rules would produce the following revised Path Matching example
> > table:
> >
> > *QXRI (Path in bold)*
> >
> >
> >
> > *XRD Path Element*
> >
> >
> >
> > *Match*
> >
> > @example
> >
> >
> >
> > <Path></Path>
> >
> >
> >
> > POSITIVE
> >
> > @example
> >
> >
> >
> > <Path match="null"/>
> >
> >
> >
> > POSITIVE
> >
> > @example
> >
> >
> >
> > <Path>*/*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/
> >
> >
> >
> > <Path></Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/
> >
> >
> >
> > <Path>*/*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*/*
> >
> >
> >
> > <Path></Path>
> >
> >
> >
> > NEGATIVE
> >
> > @example/*/*
> >
> >
> >
> > <Path>*/*</Path>
> >
> >
> >
> > NEGATIVE
> >
> > @example/*/*
> >
> >
> >
> > <Path>*//*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*/*
> >
> >
> >
> > <Path>*//foo*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*
> >
> >
> >
> > <Path>*foo*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*
> >
> >
> >
> > <Path>*/foo*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*/foo*
> >
> >
> >
> > <Path>*foo*</Path>
> >
> >
> >
> > NEGATIVE
> >
> > @example/*/foo*
> >
> >
> >
> > <Path>*/foo*</Path>
> >
> >
> >
> > NEGATIVE
> >
> > @example/*/foo*
> >
> >
> >
> > <Path>*//foo*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar*
> >
> >
> >
> > <Path>*/foo*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar*
> >
> >
> >
> > <Path>*/foo*bar*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar*
> >
> >
> >
> > <Path>*/foo*bar/*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar*
> >
> >
> >
> > <Path>*/foo*bar/baz*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar*
> >
> >
> >
> > <Path>*foo*bar*baz*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar*
> >
> >
> >
> > <Path>*/foo*bar!baz*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar/*
> >
> >
> >
> > <Path>*/foo*bar*</Path>
> >
> >
> >
> > NEGATIVE
> >
> > @example/*foo*bar/*
> >
> >
> >
> > <Path>*/foo*bar/*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar/*
> >
> >
> >
> > <Path>*/foo*bar/baz*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*foo*bar/*
> >
> >
> >
> > <Path>*/foo*bar*baz*</Path>
> >
> >
> >
> > NEGATIVE
> >
> > @example/*foo!bar*
> >
> >
> >
> > <Path>*/foo*bar*</Path>
> >
> >
> >
> > NEGATIVE
> >
> > @example/*foo!bar*
> >
> >
> >
> > <Path>*/foo!bar*baz*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*(+foo)*
> >
> >
> >
> > <Path>*/(+foo)*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*(+foo)*bar*
> >
> >
> >
> > <Path>*/(+foo)*</Path>
> >
> >
> >
> > NEGATIVE
> >
> > @example/*(+foo)*bar*
> >
> >
> >
> > <Path>*/(+foo)*bar*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*(+foo)*bar*
> >
> >
> >
> > <Path>*/(+foo)*bar*baz*</Path>
> >
> >
> >
> > POSITIVE
> >
> > @example/*(+foo)!bar*
> >
> >
> >
> > <Path>*/(+foo)*bar*</Path>
> >
> >
> >
> > NEGATIVE
> >
> > Feedback? Votes?
> >
> > =Drummond
> >
