Re: Boeing XRI Use Cases

Thanks for the input Paul,

The XRI-TC was under the impression that IRI/URI scheme was intended  
to be the in-URI trigger that a URI is not just a simple http: URI.

If the consensus opinion of the TAG is that we should not use a scheme  
for this then we do need an alternate general purpose naming extension  
mechanism for http:.

I would submit that it is not the proper role of the XRI-TC to inflict  
such a thing upon the http: scheme.

A number of the suggestions from this thread put forth different ideas  
for doing something special within the http: scheme for XRI.

I will point out that XRI and HXRI is being used now as specified by  
the XRI 2.0 committee spec.

The longer we delay in documenting changes the grater the pain for  
users down the road.

I think having a general mechanism for this within the http: scheme  
that would be preferable, though the XRI-TC can not reasonably wait an  
indeterminate amount of time while this is sorted out by the TAG or  
others.

At this point I see the leading idea as.

1. Keep the xri: scheme but prohibit its use in the IRI form, and  
direct XML authors to use http: URIs for naming.  There is no good  
reason to use xri: scheme URI's for namespaces.  (read ditch IRI for  
XRI)
2. Keep the current form of HXRI using the proxy resolver at xri.net  
or any other local proxy people choose to put up.  (no special DNS  
naming convention)

Thats where I am at the moment looking at the feedback.

I am not emotionally attached to the xri: scheme as long as an  
appropriate mutually agreeable naming extension method can be found  
for the http: scheme.

Regards
John Bradley
OASIS IDTRUST-MS
http://xri.net/=jbradley


On 16-Jul-08, at 2:12 PM, Paul Prescod wrote:

> I don't think that your analogy is quite right. The problem is not  
> that two different URIs address the same resource. The problem is  
> that third-parties are encouraged to make general-purpose software  
> that pulls apart *any* URI and infers something about it on the  
> basis of whether it matches that pattern or not. That software will  
> make the wrong inference if it encounters a legacy URI that just  
> happens to match the pattern.
>
> That said:
>
>  * URIs of the form http://.../something:/... are quite rare. I  
> don't remember having seen one in the wild everywhere.
>
>  * If there is demand out there for an in-URI trigger that a URI is  
> "not just a simple HTTP URI" then I don't personally see that it  
> would be bad or wrong for the powers that be to standardize a  
> general purpose naming-extension mechanism.
>
>  * People who pretend that there is such a mechanism when there is  
> not, ARE in danger of doing real harm, but the devil is in the  
> details. For example, if the magic-triggering string were a UUID  
> then the chances would be infinitesimal.
>
>  * a general-purpose naming-extension mechanism might be in some  
> sense backwards incompatible (adding meaning to existing URIs), it  
> seems to me that there are companies out there with databases of  
> URIs that could tell us what the likely scale of the breakage would  
> be. i.e. one in a million indexed URIs?
>
> The situation is not much different from the risk of clashing  
> attributes in XML which gave rise to XML namespaces.
>
>  Paul Prescod
>