I want to start by thanking the 73 OASIS voting members who voted fort the XRI 2.0 spec I know there were others who wanted to vote in favor but couldn't get there votes cast in time due to there organizations voting reps being unavailable.

There were others who supported us but did not vote due to a company policy to not vote on specs they are not directly involved in.

I especially appreciate the votes from the Liberty Alliance, AOL, Boeing, Oracle, Novell, Nortel, Intel, EMC, Corel and the US Department of Defense to name a small number of our supporters.

The vote had close to a record 33% turn out with only two other votes in OASIS getting higher turnouts.

We did so well it is unfortunate that we lost the vote.

Yes according to OASIS rules we needed a 75% + 1 supermajority to pass.

We missed the mark by one no vote.

Perhaps there is room for compromise with the W3C though negotiating from our current position with a group who is fundamentally opposed to our existence can be a bit of a challenge.

It remains to be seen how well the small companies that comprise the majority XRI-TC can continue this fight that has become more political than technical.

XRI will not disappear. The question that will be asked, is why should we put in the effort to go through a standards body like OASIS, when other organizations like OpenID, oAuth and the like don't .I have to this point believed that there is value in the peer review process.

However that didn't happen in this case. Certain groups saved there criticism and comments until the XRI-TC's hands were tied by the process itself. We did make changes as a result of the review process.After that process is done the TC can not modify the spec in any way. There is no way to make a non normative text change as some suggested.

This no vote sends us back to the start of the OASIS process. We need a new draft spec that the committee must approve etc. At the fastest possible pace we are looking at 6 months to bring it back for a vote.

I must say that the XRI 2.0 spec still stands as committee spec and continues to be referencible.Many OASIS committee specs are never put to a full vote, so the XRI 2.0 will continue to live on as a committee spec.

I will keep people updated on any progress or contact that is made with the W3C, and plans for XRI 2.1.

Comments

There's one thing I don't get. Is the plan to make XRI a URI? We have http, mailto, xmpp, etc. that are all registered URIs, so XRI should be the same in order to get legitimacy, right? Why is this going through OASIS at all? I thought IANA registered (http://tools.ietf.org/html/rfc4395) URIs.

Do you think there is any possible compromise on the specifications? Dave Orchard gave a detailed response (http://www.pacificspirit.com/blog/2008/05/30/detailed_technical_reasons_why_im_against_xris) to the TC's rebuttal. Some of his points seem to have merit, such as potential confusion with relative URIs, version confusion and media-type encoding.

The most interesting part is that it doesn't seem that XRIs will be able to become URIs as long as they require escaping. Even the language used by XRI supporters seem to confirm this by saying that XRIs are "compatible" with URIs, which makes it sound like a parallel system. It would be better to say "We are working on getting IANA approval for the XRI scheme". To that end, is it feasible to register a provisional (http://tools.ietf.org/html/rfc4395#section-3) URI scheme? That would get you feedback from IANA and the IETF as well.

The XRI-TC is open to compromise if there is technical merit to the argument.

I understand from the source documents the date of Mr Orchard's review was 2005, as well the documents he refers to are all from a much earlier version of the spec.

I can tell you that Mr Orchards 2005 analysis was not communicated to us until after the public comment period had closed, and we were well into the last week of the vote.

I am certain that this was simply an oversight by Mr Orchard and the W3C TAG.

They did send us a list of questions during the review process that the XRI-TC responded to . Unfortunately the TAG from there mailing list may not have read the spec being voted on, or reviewed our response to there questions.

I would greatly appreciate a detailed discussion with the W3C regarding our current XRI 2.0 spec. If as a result of that there are issues that need to be addressed, we will deal with them.

I am at this point not convinced that Mr Orchards comments are correct with respect to our current spec.

I will also note that XRI are fully internationalized, and are intended to fit the newer W3C IRI pattern. So may well not be considered URIs without escaping. That is a feature.

I will also point out that XRI were designed as the data addressing scheme for XDI. In fact it was one project until Visa intentional asked for them to be separated a number of years ago.

In XDI an XRI address has noting to do with URL or URI it is structured identifier for describing and accessing data from a distributed data store.

I will note that the W3C also objects to XDI as they believe, that SPARQL is a superior solution. I think there are uses for both. This however is another topic.

The XRI-TC will review our options over the coming weeks and give close scrutiny to the comments made by the OASIS voters and other interested parties.