The interference of the W3C in the XRI vote at OASIS is unprecedented and disturbing. The W3C has rebuffed all efforts by the XRI TC to engage in any form of dialog about the technical merits of XRI. Despite repeated attempts by the XRI community to show the use cases that XRI is solving the TAG make vague statements like 'you can do everything in URL'... This statement is clearly and patentley meaningless without specifics....
It all well and good that SOME of the stuff that XRI does CAN be done in URI/URL but without specifying a STANDARD way of doing stuff the ability to do it is next to useless!!
There are parts of XRI that you simply CAN NOT DO with URI.... Like resolve an abstract identifier (urn).
There are hundreds of millions of users with services that use the xri specs (OpenID being the best known). The ONLY reason W3C cares about this is they think they CONTROL the internet and here is a spec that OBVIOUSLY solves wide reaching problems and it's not theirs.
In my mind this is as subversive as the Net Neutrality issue... W3C is cynically trying to stifle innovation for pure 'not invented here' reasons.
rant rave grr huff.... This pisses me off... PLEASE.... if you voted NO on the xri vote spend some time on the phone with me and talk with me about why you voted no and why I think you are wrong! Before undermining LOTS of hard work by LOTS of smart people at least understand the technology.
Subscribe to:
Post Comments (Atom)
2 comments:
Hi Andy, just a curious onlooker that has some questions:
Why couldn't an abstract URI or PURL eg. 3n265n2.name be used as the identifier like an i-number and registered for 10 years - along with another user-friendly named URI eg. craigoverend.name for locating something analogous to XRDS be done?
You can then have multiple names pointing to the one persistent URI. Persistence being a management issue just as paying for hosting to serve up the resources at the URI is. This is my understanding of why the W3C have their stance. That of managing i-numbers or persistent URNs should users stop paying for their i-name(s) to a point it becomes unsustainable.
Of course there's more than just i-numbers, there are i-names that with abstractions for naming could be transformed with Joe Gregorio's URI Templates(?) or some other standard.
Rules for:
@company to be transformed into company.com
=person to be transformed into person.name
If it makes interfacing easier.
The W3C has also written about when to use metadata in URIs and when content-type is preferred. Having now read Roy's thesis about REST, I can see why they may raise this with XRIs. While I don't know much about XDI or the finer details of most of the specs, my understanding is they're really an extension to the naming services and could probably be built on URIs.
Are there reasons other than those I've highlighted as to why XRIs couldn't be done with existing infrastructure?
Craig,
You ask good questions and the XRI community needs to answer them. I will attempt an answer here but can not dive into the technical depth of many others. (I am not on the XRI TC). I HOPE that the answers will be forthcoming in dialog with the TAG so we can move forward building apps that solve problems.
The question of a persistent identifier... Here I get stuck between 'can' and 'does'. I have use cases that require persistent identifiers (point at a specific instance of a legal doc and KNOW that the address will not be versioned). No one in the URI world has ever 'standardized' that a DNS name in a specific form MUST be treated as non-reasignable and ICAAN has NOT 'mandated' policy for the management of those uris... XRI has specified the form and XDI.org has mandated the policy.... Could the W3C do this.. sure... do I want to wait 3 years while they might, or might not, no. I have a requirement TODAY and can either 'role-my-own' or use something that a bunch of smart people have worked on for years (and that got 70+ supporting votes in OASIS process).
In terms of transforms... we are working closely with the people that run one of the TLDs to provide exactly the kind of capability.
From a high level I find it interesting and valuable to be able to assign ids to 'anything' and then discover what services are available about that entity. The entity might might not have a 'web page' it might only have a physical mailing address.. So why MUST this be discovered over http from a uri?.. Why not use a phone number over PSTN? That infrastructure is even older than http.
At a low level, and this is where me real interest is… For the data portability stuff that I am working on (call it XDI if you like) the cross-reference syntax that XRI provides is a requirement. Like above… could I create my own syntax for describing cross ref relationships in uri… sure… but I would much rather use something someone else has thought about and defined in a standard.. there is NO cross ref syntax defined for uris.
As far as I can tell the W3C position doesn’t help me as an app developer in any way… They say “we COULD do that” but they haven’t, nor have they indicated they are going to. But they also seem to be saying that no-one else can do it either… or at least if they do do it they HAVE to do it a certain way.
No-one is saying “the world MUST use XRI”… they are just saying “if you want to use XRI, this is how you should do it.” Why would the W3C care… If I have to role-my-own, I will HAVE to tell my customers “if you use my stuff, this is how to use it”… My guess is anything I invent in my office in a vacuum would be inferior to the work of the TC… no?
Another point that I think is worth pointing out, even if it has nothing to do with the XRI issue: people compare the ‘cost of ownership’ of an i-name with the cost of a domain name and say it’s just a way for some guys to make some money… If I want to give ‘all my users’ uris like: bob.name, sally.name, etc… I have to buy each one an SSL cert to do anything secure with it so cost of ownership is hundreds of dollars a year.. i-names use security mechanisms that avoid this cost… I wander if the W3C campaign against XRI has been sponsored by Verisign ;-)
Post a Comment