OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Re: content negotiation for site-meta


/site-meta itself it going to define a single format. Anything else will have to define its own extension so imposing a .txt on the generic version makes little sense. The real question is if there is value in an XRD version, considering the data might not perfectly overlap.

 

EHL

 

From: sappenin@gmail.com [mailto:sappenin@gmail.com] On Behalf Of David Fuelling
Sent: Monday, December 15, 2008 8:28 PM
To: Eran Hammer-Lahav
Cc: Brian Eaton; xri@lists.oasis-open.org
Subject: Re: [xri] Re: content negotiation for site-meta

 

Full overlap aside, couldn't you just specify that the textual version can be found at /site-meta (or /site-meta.txt), and the XRD version can be found at /site-meta.xrd?

david

On Mon, Dec 15, 2008 at 9:05 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I agree with your analysis. What makes me reconsider this is the lack of full overlap between /site-meta (text) and XRD. In my previous email you can see where I had to add another namespace to support <site-meta:scheme>. Since the text format will be required in any compliant implementation, maybe we should not support an XRD flavor of /site-meta.

EHL




On 12/15/08 12:18 PM, "Brian Eaton" <beaton@google.com> wrote:

On Thu, Dec 11, 2008 at 11:40 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> At the /site-meta level, there will be a facility to describe URI mapping
> via a URI template. /site-meta will have a canonical TEXT representation
> (Mark will hopefully push it out soon) instead of the current XML. XRD will
> define an XRD-based version of /site-meta so that a GET on /site-meta with
> Accept: application/xrd+xml will produce an XRD version of the same content
> (or just return the text format).

I'm concerned that this approach will slow or stall deployment of
site-meta because it relies on HTTP features that are not
well-supported in current software.  There are three problematic parts
of the architecture: the web servers, the intermediate caches, and the
clients. =)

I've done a bit of digging and written up my notes here:
http://wiki.oasis-open.org/xri/XrdOne/ContentNegotiation

Cheers,
Brian

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]