Hmm.
The following row is from the ED06 table:
@example/foo*bar <Path>foo</Path> NEGATIVE
And this one is from your revised table in the mail:
@example/foo*bar <Path>/foo</Path> POSITIVE
I understand the added slash due to the new proposal. But why is one negative and the other positive?
In which way should the "subsegment stem matching"
work? If I have QXRI @example/foo*bar, I would
expect it to match <Path>/foo</Path>, and I would not
expect it to match <Path>/foo*bar*baz</Path>.
But according to the text, it works the other way round.
Markus
On 10/23/07, Drummond Reed
<> wrote:
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
