[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. One possibility for handling language in an XRD document is to do the same as HTML and Atom... allow the XRD consumer to request a specific language in the HTTP request. That absolutely would work, and it would build on the way HTML and Atom handle this. However, this binds XRD to the HTTP transport, and makes the document so that it is no longer self-contained. You don't have a common descriptor for the resource, you have one for every language, all of which must be handled separate because they have different signatures and potentially different expirations. The TC decided that it was more important that XRD remain transport neutral. Putting all translations into a single document does make the document that much larger; we are very aware of that. But in practice, XRD providers will likely provide titles in only a few languages based on their audience, so the additional bits will likely not be too much of a concern. (Eran, feel free to correct me if I missed something regarding language context) -will On Dec 13, 2009, at 4:35 PM, Martin Atkins wrote: > > Agreed. It's not clear to me what this title is expected to be used for. > Are there any actual use-cases for it? > > The really generic name it has makes me think that it's been thrown in > just because it felt like there should be a human-readable description > somewhere, but it seems better to me to actually think about what it's > for an actually name the element after that, or if it's not really for > anything then remove it entirely. > > Santosh Rajan wrote: >> Yes indeed, maybe I am missing the point. Unfortunately there are a few >> things an ordinary developer like me cannot fathom and hence I will >> appreciate if you will explain it to me. >> >> 1) Who are the humans who are going to read the XRD? >> 2) The only humans I can think of, are the developers. And only when either, >> they are writing the XRD, or when they are debugging the XRD. >> 3) Personally as a developer I would really only be concerned by the "Rel" >> values of the links. And language does not matter to me here. >> 4) And if as a developer, I would like to convey some human readable >> information to fellow developers, XML provides a "Comment" tag, which does >> not restrict me only to the title element. Using comments I can convey any >> information in any language for every element in the file. >> >> This whole "title thing" looks like a "solution looking for a problem" >> rather than a "problem looking for a solution". >> >> Can you please give us a good argument why you need multiple titles in >> multiple languages? >> >> On Sun, Dec 13, 2009 at 11:09 AM, Drummond Reed >> <drummond.reed@cordance.net>wrote: >> >>> Santosh, I think you're missing the point. Titles are for human >>> consumption. Humans speak more than one language. So if you want an XRD >>> editor to be able to display the title for an XRD link to a human in more >>> than one human language (English, French, Arabic, Greek, etc.), then you >>> need multiple <Title> elements: >>> >>> <Link rel="http://example.com/example-rel"; href=" >>> http://example.com/example-uri";> >>> <Title xml:lang="en">Example Title in English</Title> >>> <Title xml:lang="fr">Titre d'exemple en français</Title> >>> </Link> >>> >>> =Drummond >>> >>> >>> On Sat, Dec 12, 2009 at 7:49 PM, Santosh Rajan <santrajan@gmail.com>wrote: >>> >>>> Ok I will rephrase the questions. Why would a machine readable format for >>>> machine based information, require more than one language in its link >>>> element title? Any specific use case you have come across? >>>> >>>> >>>> On Sun, Dec 13, 2009 at 12:57 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote: >>>> >>>>> Re #1: not if we want it to express multiple titles, each with a >>>>> different language. >>>>> >>>>> >>>>> >>>>> I could not figure out what you were trying to say with the rest of your >>>>> points. >>>>> >>>>> >>>>> >>>>> EHL >>>>> >>>>> >>>>> >>>>> *From:* Santosh Rajan [mailto:santrajan@gmail.com] >>>>> *Sent:* Saturday, December 12, 2009 7:06 AM >>>>> *To:* xri-comment@lists.oasis-open.org >>>>> >>>>> *Subject:* Re: [xri-comment] XRD <uri> vs. Link: anchor= >>>>> >>>>> >>>>> >>>>> Right. In that case it would be better for XRD to specify a new separate >>>>> field for language instead of multiple titles. And titles are generally >>>>> considered as cardinality 0 or 1. >>>>> >>>>> >>>>> >>>>> 1) Can't the XRD specify a language field and avoid multiple titles? >>>>> >>>>> 2) Since when, machine readable formats, and machine based information, >>>>> cannot figure out a language, if it weren't clearly specified? >>>>> >>>>> 3) So you are saying XRD speaks "machine language"?, XRD can't understand >>>>> any other machine language other than your own? Are we going back to the >>>>> stone age here? >>>>> >>>>> - Hide quoted text - >>>>> >>>>> >>>>> >>>>> On Fri, Dec 11, 2009 at 2:02 AM, Eran Hammer-Lahav <eran@hueniverse.com >>>>>> wrote: >>>>> Regarding point #2, title is left as an element because there is a >>>>> fundamental difference between XRD and ATOM/HTML. XRD does not have a >>>>> language context since it is a machine readable format for machine-based >>>>> information. ATOM and HTML almost always have a specific context language >>>>> and almost always one. This means in XRD we need to allow multiple titles >>>>> with different languages for each link. You can’t do that easily using >>>>> attributes. >>>>> >>>>> >>>>> >>>>> EHL >>>>> >>>>> >>>>> >>>>> *From:* Santosh Rajan [mailto:santrajan@gmail.com] >>>>> *Sent:* Thursday, December 10, 2009 7:15 AM >>>>> *To:* Jonathan Rees >>>>> *Cc:* xri-comment@lists.oasis-open.org; Eran Hammer-Lahav; Mark >>>>> Nottingham; Ben Adida; openid-general@lists.openid.net >>>>> *Subject:* Re: [xri-comment] XRD <uri> vs. Link: anchor= >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi Jonathan, >>>>> >>>>> >>>>> >>>>> This is only the least of the problems with XRD. As far as the "link" >>>>> element is concerned. Here are a few points I have to make. Please have a >>>>> look at this post first of all. >>>>> >>>>> >>>>> >>>>> http://hueniverse.com/2009/11/xrd-alignment-with-link-syntax/ >>>>> >>>>> >>>>> >>>>> 1) The XRD "Link" element today looks exactly like the Atom "link" >>>>> element. >>>>> >>>>> 2) Except for one difference. The "Title" element. The XRD Title element >>>>> is not an attribute in a Link element, its an element on its own right, with >>>>> the value being the title value. >>>>> >>>>> 3) This is ridiculous. They have not given a good argument for having a >>>>> title element inside the link, instead of an attribute. >>>>> >>>>> 4) And here is another very unscientific argument. The "link" element >>>>> looks very beautiful with all values described as attributes. Putting any >>>>> value, inside an element, inside a link element makes it look positively >>>>> ugly. >>>>> >>>>> >>>>> >>>>> Of cource my argument can always be brushed aside as coming from a >>>>> "crazy" as was posted here in this link. >>>>> >>>>> >>>>> >>>>> http://lists.oasis-open.org/archives/xri/200911/msg00039.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Dec 10, 2009 at 6:40 PM, Jonathan Rees <jar@creativecommons.org> >>>>> wrote: >>>>> >>>>> [ bcc: www-tag for the TAG's information. To broaden the discussion >>>>> beyond XRD change the cc: list as appropriate. ] >>>>> >>>>> XRD <uri> seems to do exactly what the Link: header's anchor= >>>>> parameter does [1]. It would be nice if the two used the same token to >>>>> communicate this function. As <uri> is not descriptive of the role >>>>> played by the URI, I recommend updating XRD to match Link:, by >>>>> renaming the <uri> element (or attribute, should you go that route) to >>>>> be <anchor>. >>>>> >>>>> Jonathan >>>>> >>>>> [1] http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt >>>>> >>>>> (p.s. I wonder if HTML5's <link> element should have an 'anchor' >>>>> attribute, for symmetry ...)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]