RE: [xri-comment] XRD <uri> vs. Link: anchor=

[Eran Hammer-Lahav <eran@hueniverse.com>]

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Sunday, December 13, 2009 5:35 PM
> To: xri-comment@lists.oasis-open.org
> Subject: Re: [xri-comment] XRD <uri> vs. Link: anchor=
> 
> To Drummond's use case... if I'm a service provider, and I want to provide a
> tool for users to edit their discovery documents to some degree, the <Title>
> element isn't really useful to me because I'm not going to be using the XRD
> document itself as my data store.  I'm going to have some kind of relational
> database which powers the application.  After the user is done editing, the
> OUTPUT of that process will be an XRD.  Titles are not really intended to be
> used by the XRD provider, but rather by the XRD consumer.
> 
> I think a better example is how browsers handle multiple RSS/Atom feeds on
> a website.  When I got to my site (willnorris.com), Safari displays the grayish
> little "RSS" icon in the address bar.  When I click on it, a small menu pops
> down giving me two different feeds to select from, "Will Norris Posts RSS
> feed" and "Will Norris Comments RSS feed".  Both of those links have the
> same rel value, "alternate", as well as the same media type
> "application/rss+xml".  The only difference is the URL and the title, and
> showing the URLs to a user to select from is meaningless.  Therefore, title
> provides the necessary description that I as a user need to make an informed
> decision on which feed I want to subscribe to.
> 
> Now translate this to XRD.  If I have a photo uploader app that is XRD aware,
> it can fetch my discovery document and offer to upload a photo to "Will's
> Flickr photo service" or "Will's Picasa photo service", or whatever my titles
> may be.  Anytime an application is retrieving data from an XRD, and needs to
> convey that data to a user in some way, titles become very helpful, if not
> outright necessary.
> 
> 
> 
> And to more fully explain something Eran replied to Santosh a few emails
> ago, but I think got missed a little bit. Why would we need multiple titles for a
> link?  As Eran stated, XRD has no language context.
> 
> One of the goals of XRD is for the descriptor to be entirely self-contained.
> This is why some of the alternate signing methods were rejected, because
> they relied on the signature itself being carried in an HTTP header.  We
> specifically did not want to bind XRD to a specific transport mechanism.  This
> is also why XRD has its own expiration date, instead of just relying on the
> caching semantics available to certain transports.
> 
> HTML and Atom documents have language context.  Typically, though not
> always, all of the human readable content in a given HTML or Atom
> document is in a single language.  Different translations of the same
> document can be retrieved by using the "Accept-Language" HTTP header,
> and the actual language of a document can be declared in the "Content-
> Language" response header.

While content negotiation is relevant, ATOM and HTML almost always have a context language, and almost always does not support other languages. ATOM uses xml:lang to declare its language and it is simply inherited by the link titles. If we applied this model to XRD, XRD would simply declare somewhere that all the human-readable values are in a specific language and be done. But I feel this is a limited model that does not work well with where the web is heading with regard to internationalization.

XRD is hopefully going to popularize link usage beyond its currently limited role. Same with the Mark's work on Web Linking and HTML5 on cleaning links. It would be bad if we didn't take internationalization seriously.

EHL