[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
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] 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:
Feedback? Votes? =Drummond |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]