RE: [xri] XRD Type and Path specification

["Drummond Reed" <drummond.reed@cordance.net>]

Oops. Wrong citation. To close on this thread, the following was recorded in the minutes of the 2006/05/25 TC telecon:

 

* Regarding whether XRIs in an XRDS document needed to be encoded in URI normal form, is currently specified in section 3.4. Wil suggested we add an additional reference to this in sections 8.2.2 and 8.2.4.

 

=Drummond

 

---

From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Saturday, May 27, 2006 12:02 AM
To: 'Tan, William'; xri@lists.oasis-open.org
Subject: RE: [xri] XRD Type and Path specification

 

To close on this thread, the following was recorded in the minutes of the 2006/05/25 TC telecon:

 

* We discussed Wil's proposal in

http://lists.oasis-open.org/archives/xri/200605/msg00033.html to add support for wildcard matching. The conclusion was that we will emulate HTTP Accept headers and add * wildcard parameter support in the QXRI input parameter.

However we will not support publishing wildcards in the value of a MediaType element in an XRD because the server needs to be more explicit about what it supports.

 

=Drummond

 

---

From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Wednesday, May 24, 2006 6:36 AM
To: xri@lists.oasis-open.org
Subject: [xri] XRD Type and Path specification

 

Hi folks,

 

We do not seem to mention what normal form should the value of Type and Path elements be.

 

I would normally prefer XRI-normal form since there is no issue with XML, but because of the following reasons:

 

1. Query is already defined to be in URI-normal form; and
2. It may be easier to parse since we can simply index the slash character to strip off path segments without any knowledge of xrefs, though it is still necessary to parse xrefs in order to properly determine subsegment boundaries.

 

I suggest putting a SHOULD/MUST for URI-normal form.

 

Also, with regards to path matching rules, I’d like to clarify what I understand from the spec:.

E.g.

 

<Path>(+foo)</Path>

 

QXRI: xri://@a/+foo/bar

We try:

1. +foo/bar => no match
2. (+foo/bar) => no match
3. +foo => no match
4. (+foo) => match

 

 

QXRI: xri://@a/(+foo)/bar

We try:

1. (+foo)/bar => no match
2. ((+foo)/bar) => no match
3. (+foo) => match

 

 

QXRI: xri://@a/(+foo/bar)

We try:

1. (+foo/bar) => no match
2. Since (+foo/bar) is already a xref we don’t add the optional parentheses

 

 

Are these processing steps correct?

 

 

=wil (http://xri.net/=wil)