[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] ED07 Issue #2: Leading Slash in Path Element
Wil, in general I agree with you about "all slashes signficant". However since the goal of the Path element is to support path matching for SEP selection, it seems like if we enforce that rule strictly, we're making it much harder than it needs to be for XRD authors. If we go the opposite way and make the rule that the leading forward slash on the path is ALWAYS assumed even if it is not present in an <xrd:Path> element, then the four corner cases of the QXRI path being empty and the Path element being empty all net out the same way: QXRI PATH ELEMENT MATCH =example <Path></Path> POSITIVE =example <Path>/</Path> POSITIVE =example/ <Path></Path> POSITIVE =example/ <Path>/</Path> POSITIVE The only downside I can see to this is that you can't match =example and =example/ differently. But again, this is such an edge case already with RFC 3986 that to normalize all four edge cases to the same thing seems the easiest way to go, especially for XRD authors. Whatchathink? =Drummond > -----Original Message----- > From: Tan, William [mailto:William.Tan@neustar.biz] > Sent: Tuesday, October 23, 2007 3:41 PM > To: Drummond Reed > Cc: 'Gabe Wachob'; 'OASIS XRI TC' > Subject: Re: [xri] ED07 Issue #2: Leading Slash in Path Element > > I'm in favor of it except forh rule #1 because it assumes that @example > and @example/ are the same. To me, the former has no (null) path whereas > the latter has one. > If XRD authors would like to match both, they'd have to specify both: > <Path></Path> > <Path>/</Path> > > But most likely they won't have to because it is unlikely that @example/ > will be used. And if it is used, we might want to take the same position > as the forward slash appearing anywhere else, i.e. all slashes are > significant. Not having rule #1 will make it possible to target each > case separately. > > =wil > > Drummond Reed wrote: > > 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:William.Tan@neustar.biz] > >> 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:gabe.wachob@amsoft.net] > >>> *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:drummond.reed@cordance.net] > >>> *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 > >>> > >>> > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]