A number of the No voters indicated in there comments that they were voting no at the recommendation of the W3C. Some of these indicated that there intent was to encourage a dialog between the W3C TAG and the XRI-TC.
I would like to report that on Sep 3, a joint telecon between the TAG and the XRI-TC was conducted.
In the hour conversation not much was accomplished other than introductions and basic position statements.
In the TAG minutes of July 10 the call and progress were reviewed. http://lists.w3.org/Archives/Public/w
I encourage people to read the TAG minutes re XRI and other "Social Problems", leading people to create URI schemes.
David Booth from HP and I have had what I think is a productive exchange on the precise issue that concerns him and perhaps others on the TAG.
http://lists.w3.org/Archives/Public/w
http://lists.w3.org/Archives/Public/w
http://lists.w3.org/Archives/Public/w
http://lists.w3.org/Archives/Public/w
http://lists.w3.org/Archives/Public/w
I think the point being discussed now though never raised by the W3C during the public comments period for the XRI 2.0 spec is as follows.
The XRI 2.0 spec defines XRI in four ways:
1. "XRI-Normal Form" with identifiers in the form =thread-safe (These are NFKC normalized UTF-8 strings)
2. "IRI-Normal Form" format in the form xri://=thread-safe (This is XRI Normal form escaped per Sec 2.3.2 of XRI syntax and xri:// prepended.)
3. "URI-Normal Form" in the form xri://=thread-safe ( IRI-Normal form transformed via Sec 3.1 of RFC 3987)
4. "HXRI Form" http scheme URL in the form https://xri.net/=thread-safe (URI normal form with xri: replaced by a htttp proxy resolver. http://xri.net/ in this example.)
A non normative draft refrence document on the transformations can be found at:
http://wiki.oasis-open.org/xri/XriT
The HXRI form was created to address the concerns expressed by the W3C regarding backwards compatibility several years ago.
The problem as it may turn out is not that we have documented to little in the XRI 2.0 spec but perhaps too much.
We were under the impression that the information space is URI and worked with great diligence to fit into that.
It now appears that we were mistaken.
The W3C sees the http: scheme URL space as the universal information space.
This has lead to the conclusion that no new URI schemes should be registered.
We have done the work necessary to fit into the http URL scheme.
My question is should the OASIS XRI-TC remove references in the spec to the xri: scheme?
Is there anyone who wants xri: to be a registered URI scheme?
The spec would still need to explain all the transformations required to go from XRI-Normal to HXRI but could replace xri:// with something like, this-is-IRI-form-however-it-is-not-a-reg
If actively discouraging people from using the xri: scheme transform of an XRI makes people happy, I will personally take it as a proposal to the XRI-TC.
I suspect that there are other issues lurking that the TAG has yet to clearly articulate, however this is a start. If we can deal with this then perhaps we can resolve them all.
=jbradley
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1)
thread_safe- John Bradley
- Website
Comments
That always seemed to be really hacky, but I don't see how otherwise, we can indicate that a HTTP URI should be interpreted as an XRI, for those processors that are XRI-aware.
David cant of course speak for the TAG, and I await there response to the thread.
I think there is a concern that interpreting any URL as a HXRI if it starts with https://xri.
would perhaps catch unintended URLs. We would probably need to say that the path MUST start with a GCS symbol, or something like that.
https://xri.net/ could always be considered safe and preferred for XML documents etc.
There are some things that would need thinking through.
If the W3C TAG is clear that this would eliminate there objections then we could work up a proposed set of changes in a relatively short period of time