Hi, I'd also be interested in participating in a new WG.
Of particular interest to me is the use of Atom and AtomPub in the non-blogging (enterprise) context. In addition to the list provided earlier, I have these on my list of interest: - using feeds for search results - adding a <linkTemplate> element Jan On Tuesday, June 09, 2009, at 11:40PM, "Sylvain Hellegouarch" <[email protected]> wrote: > >Martin Atkins a écrit : >> >> Nikunj R. Mehta wrote: >>> >>> Recent discussions on the atom-syntax mailing list has revealed >>> interest in creating a new WG to look at several extensions of Atom. >>> Here are several extensions that have been discussed: >>> >>> 1. Hierarchy operations including meta-publishing >>> 2. In-line representation >>> 3. Bi-directional text >>> >>> Please respond to this email if you are interested in helping to >>> explore a new WG further. Please also identify if you have a specific >>> interest area to consider for a potential new Atom WG. >>> >> >> I am particularly interested in the in-line representation part of >> this. I'm currently working with a small group on an Atom extension >> for describing activity streams[1], and frequently we've received >> feedback from implementors that they want the pertinent content to be >> inline in the feed to avoid additional fetches. >> >> ----------------- >> >> We were in fact discussing recently the use of inlining atom:link >> content to refer to external resources without necessarily requiring >> an additional fetch. I think this model is similar to atom:source in >> that it provides some non-authoritative metadata that may be >> sufficient for display purposes while providing a mechanism for >> processors to retrieve the authoritative metadata when necessary. >> >> The model we were considering was as follows: >> >> <link rel="related" type="application/atom+xml" href="..."> >> <entry> >> <id>tag:example.com,2009:123545</id> >> <title>Some Related Entry</title> >> ... >> </entry> >> </link> >> >> To my mind, the model here would be that if >> type="application/atom+xml" then the link element MAY contain exactly >> one atom:entry or atom:feed element which provides a subset of the >> information from the target document, much as atom:source does. > >Why not using atom:content for that? The inlining you're presenting >really looks like it defeats the point of the atom:link element in the >first place. > >- Sylvain > > >
