OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes: XRI TC Telecons Thur/Friday 2006/1/12-13


Minutes of the following two XRI TC telecons:

US/ASIA TELECON

Date:  Thursday, 12 January 2006
Time:  9:00pm - 10:30pm PT

PRESENT

Kunal
Mohit
Drummond
Steve

US/EUROPE TELECON

Date:  Friday, 13 January 2006
Time:  10:00am - 11:30am PT

PRESENT

Marty
Les
Gabe
Drummond
Steve
Jamie Clark (OASIS)

AGENDA

1) OASIS VOTE PREP (discussed on the Friday call only)
Jamie Clark, OASIS Director of Standards, joined us to continue discussion
of preparations for the OASIS Standard vote.

Gabe clarified that in discussion with Jamie and OASIS staff following the
decision to delay the vote in mid-December, it was decided that would be
prudent not to attempt to have the vote in February and to delay it at least
until March so that we can have the conversations necessary to ensure that
the vote will be successful.  In the meantime we are proceeding to the
Committee Specification level on the remaining specifications in the XRI 2.0
suite as quickly as possible.

Jamie explained that one step in this process he is helping with is
preparation of a more formal reply to the comments submitted by the W3C TAG
during the XRI public review period. It was agreed that this response should
ultimately become a public document in the XRI TC repository.

Marty asked to clarify the goal of this document. There was concensus that
the end goal is a successful OASIS Standard vote, and that towards this end
the purpose of this document will be both for communication with the TAG W3C
as well as to educate the rest of the OASIS voting audience. Marty felt
strongly that this communication should not be adversarial but simply
clarify that XRI was developed based on a different perspective of the use
of identifiers.

Jamie asked for input about what we felt we should focus on as the heart of
this document, i.e., the rationale for why XRIs and XRI resolution are
needed vs. just using URIs (particularly HTTP URIs) and DNS/IP.

Two potential responses: a) no, you can't do everything with HTTP URIs and
redirects, and b) that you should never rule out future identifier schemes.

TC feedback:

1) The issue of persistence is not the strongest case for XRI architecture.
It is true that XRI is the only architecture that offers a common syntax and
resolution protocol for both persistent and reassignable identifiers and a
method for establish equivalence between the two. However the proponents of
HTTP URIs may argue endlessly that you can accomplish the same thing with
careful identifier management and HTTP redirects.

2) A much stronger case is that XRI is the only identifier architecture that
implements cross-references (polyarchy), which among other things permits
identifier metadata to be included in identifiers. A wonderful example is
the NAC XRI Profile, which makes extensive use of the XRI Metadata
specification, which is based entirely on XRI cross-reference syntax.

3) Another strong suit is Gabe's argument for why Visa has been pursuing XRI
architecture (see
http://lists.oasis-open.org/archives/xri/200601/msg00002.html and
http://lists.oasis-open.org/archives/xri/200601/msg00003.html.) Gabe's
"stitching" argument about "what may be closed now may later become open" is
a very strong one for the XRI authority model, which is much more flexible
than HTTP URIs.

4) Another key point is that XRI offers an identifier architecture that is
fully compatible with the Web but may also extend to resources that are not
on the Web. This applies to a closed body of data that is behind firewalls
and not available on the Web (but which may one day become available on the
Web.)

5) Lastly, a final key point we should be making is that with the revised
XRI 2.0 resolution framework, we have achieved a high level of backwards
compatability with HTTP URIs, i.e., there is a defined transformation of all
XRIs into an HTTP URI format (which we call "HXRI").

This last point is important because it, together with the fact that XRI
Syntax defines a transformation of an XRI into an IRI, shows that we are
making sure XRI is compatible with W3C TAG architecture. Furthermore XRI
ends out being a case in point of the adaptability of URI syntax that W3C
has long championed -- it is one of those identifier schemes that
illustrates the need to allow for the continuing evolution of identifiers.
Marty pointed out that XRI is in the same category as IRI in this respect.

We then discussed the potential form of the W3C TAG response. Jamie proposed
that OASIS staff make the response, with support from the TC in the form of
the document discussed above. 

Finally, we discussed other preparations for the vote. Jamie suggested that
historical evidence at OASIS shows it is worth campaigning if a TC has a
good pitch. Who should do it? Jamie said that the TC and OASIS staff need to
work together to decide this.

The final action items from this discussion:

ACTION ITEM: DRUMMOND, GABE, MARTY to begin TC work to create the "XRI
Rationale" document discussed above (beginning with choosing a name for this
document.)

ACTION ITEM: GABE, MARTY, and JAMIE as the "vote preparation coordination
committee" need to decide which conversations need to happen with whom.


2) METADATA REPORT
Marty and Drummond briefly reported that they are in the final stages of
preparing XRI Metadata 2.0 Working Draft 08. They will direct further
questions to the email list.

3) XRI RESOLUTION REF PROCESSING ISSUE
At the very end of Friday's call, we discussed the proposal from Steve
Churchill for how to handle recording XRD elements that result from
following a Ref element into an XRDS document. See:

	http://lists.oasis-open.org/archives/xri/200601/msg00019.html

The conclusion was that we should follow this general pattern but use nested
XRDS documents instead of introducing a new element.

ACTION ITEM: XRI Resolution 2.0 editor's team to incorporate this into the
next editor's draft.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]