RE: [xri] ED07 Issue #2: Leading Slash in Path Element

Markus, see [=Drummond] line.

 

From:
 [mailto:] On Behalf Of Markus Sabadello

Sent: Wednesday, October 24, 2007
8:39 AM

To: Drummond Reed

Cc: OASIS XRI TC

Subject: Re: [xri] ED07 Issue #2:
Leading Slash in Path Element

 

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?

 

[=Drummond]
My mistake – working too fast. See below.

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.

 

[=Drummond]
Right, it does work the other wah round (that’s the mistake I made above).
The Path String from the QXRI must be a SUBSET of the <Path> element
value. The reason we specified it this way is that we were approaching it like
directory tree navigation. For example, if I have the following directory tree:

                   /
(Root)

     a         
   b           c

    
/             /

  x    y        m 
  n

  /

  z

Then the following
are valid paths in this tree:

          /

          /a

          /b

          /a/x

          /a/y

          /a/x/z

          /b

          /b/m

          /b/n

          /c

 

Our logic was that if you chose one of
these paths as the <Path> element value, then any Path String from the QXRI
that fell within that path should be a match. For example, if you specified
<Path>/a/x/z</Path> in an XRD, then would be five QXRI Path String values
that would be a POSITIVE match because all of them would be “in this path”:

 

          /a

          /a/

          /a/x

          /a/x/

          /a/x/z

 

Any other QXRI Path String values would be a
NEGATIVE match.

 

Does that make sense?

 

=Drummond 

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