W3C home > Mailing lists > Public > www-tag@w3.org > July 2008

Re: [XRI] TAG recommendation

From: Stuart Williams <skw@hp.com>
Date: Fri, 18 Jul 2008 22:57:32 +0100
Message-ID: <488111CC.4060109@hp.com>
To: John Bradley <john.bradley@wingaa.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>

Hello John,

John Bradley wrote:
> Stuart,
>
> We have been at the XRI discussion on the list now for over a week.
>
> I have not seen any concrete issue other than the use of a URI scheme 
> surface.
Wrt to URI schemes, I think Henry stated the TAG's position which 
prioritises reuse over introduction of new scheme where it believes new 
schemes need to deliver clear capabilities that cannot be addressed 
using existing schemes. The TAG's position has been that it is 
unconvinced that the requirements that motivate XRIs cannot be meet 
using existing URI schemes - specifically http:. Your characterisations 
of the TAGs position elsewhere state it somewhat more categorically than 
I would care to.

Anyway... to answer your question... they are certainly a big part of 
the issue.

A possible related secondary issue is the promulgation of identifiers 
that are not URI - specifically, were formats to be specified on ways 
that encouraged the use of abbreviated forms (eg i-name or i-numbers) to 
the exclusion of URI forms - I believe the TAG would have issues. I'm 
not familiar enough with OpenID and OAuth, but I have heard bells 
possibly going off. My belief is that the TAG would prefer the use of 
URI/IRI forms of identifier abbreviated if you like through the use of 
base URI and relative forms or, possibly through adoption of CURIE 
syntax (not quite a W3C recommendation yet).
> Given that this started as a result of a TAG recommendation 
> http://lists.w3.org/Archives/Public/www-tag/2008May/0078
> that indirectly affected the OASIS standard vote for XRI 2.0.
>
> Is it the position of the TAG and others on the list that the move 
> away from using a URI scheme is sufficient for the TAG to withdraw its 
> recommendation subject to agreed changes re the scheme?
Firstly I can't speak for the TAG without the TAG having reached some 
sort of a concensus on question that it is ready to answer. 
Unfortuately, summer time availability of TAG members making it 
difficult to assemble critical mass to establish concensus.

You've certainly seen a direct answer from David Orchard [1].

[1]  http://lists.w3.org/Archives/Public/www-tag/2008Jul/0025
>
> If there are other issues that need to be resolved from the TAG's 
> point of view we should surface them.
In the questions that the TAG raised in [2] the 2nd question was whether 
XRI resolution used of HTTP content negotiation to negotiate between the 
retrieval of a representation of a denoted thing (an HTML/PDF... 
serialisation of a document) and the retrieval of metadata *about* the 
denoted thing - that being an abuse of HTTP content negotiation.

The response in [3] begins " Yes, local resolvers or proxy resolvers can 
do this on behalf of a client (authority servers only handle XRDS 
documents)." If HTTP Accept: headers are being used as a signal to 
indicate whether or not metadata is being sought then the TAG would 
regard that as counter to web architecture (different URI for resource 
and its metadata - itself a distinct resource, is fine).

[2] http://lists.w3.org/Archives/Public/www-tag/2008Feb/0009
[3] http://lists.w3.org/Archives/Public/www-tag/2008Feb/0104
>
> The IDTRUST Member Section and others in OASIS would like to be 
> certain that a definitive list of issues is produced from this process 
> so that the XRI-TC can begin the process of bringing forward a revised 
> spec.
>
> I ask that the TAG consider this question at its earliest connivence,  
> given the summer schedule.
I am hopeful of a meeting on 24th July (though as I indicate previously, 
we will have some absenses).
>
> Regards
> John Bradley
> OASIS IDTRUST-SC
> http://xri.net/=jbradley
> 五里霧中

Regards

Stuart Williams
--
Received on Friday, 18 July 2008 21:58:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:23 UTC