Hi James, On Mon, May 17, 2010 at 9:47 PM, James Snell <[email protected]> wrote: > > Ok, draft is updated with the new syntax for the hash attribute. > > http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt
+1. Looks good. (I like the whitespace-separation too, much better than comma+opt. space.) Just a thought though. I think using the null-namespace is good, and that this updating of the Atom syntax seems very reasonable. But does the informational status of the RFC warrant such an addition to the syntax? I mean, since it seems like a very authoritative thing to do to Atom spec. > There is also one additional 'media' attribute added. I wanted to wait > to add it until after I was sure the other three attributes were fine. > The 'media' attribute serves the same purpose as the 'media' attribute > on HTML5 links... the value is a media query. For example: > > <link href="foo" media="handheld and (min-width = 20cm)" /> Sounds quite good (as long as it is aligned to the HTML5 variant -- and if that one is stable). If this won't slow down the progress to an RFC I'm all for it. > The use case is to be able to provide multiple links targeted at > specific types of media... e.g. screen, print, mobile devices, etc. > > Another change that I am contemplating making is introducing a new > child element for the atom:link element that would allow it to serve > the same basic purpose as the GData feedLink and entryLink elements > except with greater flexibility... specifically, it would allow a > representation of the linked resource to be dropped directly into the > link element, e.g. > > <link rel="alternate" href="foo" type="text/plain"> > <data type="text">this is a representation of the data</data> > </link> > > <link rel="alternate" href="foo" type="image/jpeg"> > <data type="encoded">abc...def==</data> <!-- base64 --> > </link> > > <link rel="alternate" href="foo" type="application/atom+xml"> > <data type="markup"> > <feed>...</feed> > </data> > </link> > > Or something along those lines. I do think that this is a good idea. However, could it perhaps be better as a separate I-D (link-content-embedding or something)? While I agree that it's about link extensions, the current scope is around attributes around which I think we have reached a general consensus. I suspect that this new element might take longer to iron out and reach the same level of agreement with? (Since there have been similar propositions over the years.) Again, I'm mostly just after getting the link-extensions to an RFC state as soon as possible. (Especially since we use the older, namespaced md5-attribute in our system today, and I would prefer to defer support for this new version (null-namespace, hash) until the I-D becomes an RFC.) Thanks again for revitalising this! Best regards, Niklas
