You are viewing thread_safe

Previous Entry | Next Entry

XRI 2.0 Vote 74% positive!


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.

Regards
=jbradley

Comments

( 4 comments — Leave a comment )
james.anastasios.id.au
Jun. 2nd, 2008 05:11 pm (UTC)
URI vs XRI
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.
thread_safe
Jun. 2nd, 2008 08:34 pm (UTC)
Re: URI vs XRI
Thanks James,

Yes the plan, and part of what the W3C appears to be objecting to is our intent to register the xri:// scheme with the IANA.

The IANA process is a separate one and not circumvented by any OASIS vote.

It has been noted that the IANA has not been approving a lot of new schemes recently.
And certainly none that are not backed by an approved spec by the W3C or other standards body.

OASIS is valuable for providing IPR protection to the people who choose to adopt its standards. All the TC members and there companies have agreed to abide by the OASIS IPR policy.

OASIS also provides a valuable peer review process. Some specs choose to not submit themselves to that process.

The members of the XRI-TC feel it is better to submit ourselves, and our spec to wide scrutiny by people beyond the spec authors.

Sometimes not everyone agrees with you. That is sometimes not a bad thing.

We will continue with our work. I hope that we can create a dialog with the W3C TAG that will allow us to understand and address there concerns.

If they are addressable.

Certainly more work is necessary on our part to help people understand and support the XRI 2.0 spec.

Thanks for your interest.
=jbradley



Edited at 2008-06-02 08:39 pm (UTC)
james.anastasios.id.au
Jun. 3rd, 2008 09:47 am (UTC)
Re: URI vs XRI
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.
thread_safe
Jun. 4th, 2008 01:28 am (UTC)
Re: URI vs XRI
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.

=jbradley

Edited at 2008-06-04 01:30 am (UTC)
( 4 comments — Leave a comment )