Re: [xri] Aligning XRD with Link (Header/Element)

[John Bradley <jbradley@mac.com>]

Adoption is huge when you consider that this also impacts the existing base of URI openIDs as well.

Telling openID providers that every user will have to have an old style XRDS and a new style XRD as separate documents is going to be a hard sell.

This may be the best time but we need to keep in mind that real people are using this now and we need to transition them in some plausible way.

The first thing we need to consider is the question of should Service be kept for concrete resources and Link used only for abstract?

=jbradley

On 25-Nov-08, at 12:45 PM, njones@ouno.com wrote:

John,

As Drummond mentioned this is the best time... As adoption is not huge, and we can end of life the Service nodes, while supporting Link too. So that can be an option for backwards compatability.

Nika

---

From: John Bradley <jbradley@mac.com>
Date: Tue, 25 Nov 2008 12:38:45 -0800
To: Drummond Reed<drummond.reed@cordance.net>
CC: OASIS XRI TC<xri@lists.oasis-open.org>; David Orchard<orchard@pacificspirit.com>; David Recordon<recordond@gmail.com>
Subject: Re: [xri] Aligning XRD with Link (Header/Element)

I am really hesitant to abandon backwards compatibility with openID mostly.

Not all openID RPs are going to upgrade to XRD overnight if at all.

Existing parsers are looking for Type and Service.

I can see making Type deprecated and allowing both Type and Rel during the transition.

Service is harder to deal with unless we do a similar thing and perhaps allow a mix of SEPs

Like:

<XRD>

   <Service>
       <Type>http://example.com/relationship</Type>
       <MediaType>application/xml</MediaType>
       <URI>http://example.org/document</URI>
   </Service>

   <Link>
       <Rel>http://example.com/relationship</Type>
       <MediaType>application/xml</MediaType>
       <URI>http://example.org/document</URI>
   </Link>

</XRD>

On the other hand as Services directly encode API endpoints should we keep them for such and use <Link> to indicate that the URI is abstract and is something that needs to be resolved to get the meta-data for the Link?

I don't think abandoning some sort of backwards compatibility is a good idea.

=jbradley

On 25-Nov-08, at 12:17 PM, Drummond Reed wrote:

Ever since Eran explained this at the IIW and XRI TC F2F sessions two weeks
ago, I've been wondering this same thing. Given that XRDS/XRD has probably
penetrated <1% of its eventual installed user base if successful, now's the
time to make this change if ever.

I find the direct mapping of semantics compelling, especially as XRD spreads
out to a much larger audience of developers.

Question: would <Type> become <Rel> under the parent XRD element as well, or
would that remain <Type>?

=Drummond

-----Original Message-----

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]

Sent: Tuesday, November 25, 2008 12:00 PM

To: xri@lists.oasis-open.org

Subject: [xri] Aligning XRD with Link (Header/Element)

As currently proposed:

<XRD>

   <Service>

       <Type>http://example.com/relationship</Type>

       <MediaType>application/xml</MediaType>

       <URI>http://example.org/document</URI>

   </Service>

</XRD>

Is semantically equivalent to:

HTTP Header:

Link: <http://example.org/document>;

rel="http://example.com/relationship";

type="application/xml";

HTML Element:

<Link rel="http://example.com/relationship"

href="http://example.org/document" type="application/xml" />

Given that Link(s) are becoming the prominent mechanism for metadata on

the

web, I think there is great value in lining up XRD with that trend. So...

I would like us to seriously consider renaming:

Service --> Link

Type --> Rel

MediaType --> (unchanged)

URI --> (unchanged)

EHL

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php