Minutes: XRI TC Telecon Friday 2005/12/02 10AM Pacific

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

Following are minutes from yesterday's unofficial XRI TC telecon.

Date:  Friday, 2 December 2005
Time:  10:00am - 11:30am PT

Event Description:
XRI TC Unofficial Telecon to finish Committee Draft 02 cycle.

PRESENT:

Gabe
Drummond
Les
Wil
Peter
Steve
Victor

AGENDA

1) XRI RESOLUTION 2.0 FLOWCHART REVIEW

We reviewed the proposed simplified XRI resolution flowchart posted last
night at:

	
http://www.oasis-open.org/committees/download.php/15713/xri-simpliified-res-
flowchart-01.pdf

We discussed the conceptual shift embodied in this flowchart that the scope
of XRI resolution is limited to: a) returning an XRDS document for an XRI
authority, or b) returning a URI corresponding to a specific media type (or
no media type) for the resource represented by the XRI being resolved.

There was consensus that the right scope for XRI resolution is limiting
input to a QXRI (query XRI) + MediaType and output to either: a) an XRDS
document, b) a URI, or c) an error. This scope has the additional advantage
of being the same processing logic no matter whether an XRI resolution call
is made at the local client or at a proxy resolver -- the result will be the
same. The only difference is that with a proxy resolver, which is composed
of a proxy resolution server + a local client resolver, when the proxy
resolution server receives a URI back from its local client resolver, the
proxy resolution server will return it it as a redirect instead of as a
naked URI to the calling application (e.g., the browser.)

We consensus from those attending on these points, we then proceeded to
review the flowchart of the proposed logic flow (which Drummond suggests be
inserted into Working Draft 10 as a new section following the XRDS section.)

The topics discussed were:

* XRD order within a XRDS document. We agreed that either: a) we need a
separate attribute (NOT the xml:id attribute) for establishing document
order, or b) we need to explicitly specify that document order MUST be used.
Document order has the advantage of not requiring additional processing.

# ACTION ITEM: Victor to check with other implementers who had requested an
explicit attribute to see if document order will be sufficient.

* XRI redirects. It was agreed that an extra step should be added to capture
the need for processing of external synonyms as XRI redirects when no
further resolution/redirection endpoints are found.

* Type matching algorithm: We discussed whether wildcards or an attribute of
the Type element should be used to control the matching algorithm. The
former is easier and doesn't require a change to the Type element; the
latter is more "correct and beautiful" (to quote Wil).

* Type matching "overload". Gabe raised the question of why we were
proposing matching on the contents of the Type element rather than a
separate Pattern element as defined in Working Draft 09. The answer is that
since the only purpose of the Pattern element is to enable selection of a
Service element using the local part of the QXRI, and since the Type element
already serves the purpose of providing an identifier used to select a
Service element, and since the cardinality of Type as of Working Draft 09 is
0-n, why not just specify matching against one element?

2) NEXT CALL

We ran out of time to continue discussions and agreed we needed another call
in order to close these issues in time to producing Working Draft 10 by the
end of next week. We agreed to try to schedule that call for next Tuesday
afternoon.