Subject: Exploring a new WG around Atom

From: "Nikunj R. Mehta" <[email-masked]>
Date: Mon, 8 Jun 2009 13:41:45 -0700

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.

Nikunj
http://o-micron.blogspot.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Jun 2009 15:08:27 -0600

On 6/8/09 2:41 PM, 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:
> 
> Please respond to this email if you are interested in helping to explore
> a new WG further. 

I'm interested in helping with this at the IETF. Perhaps at BOF at the
Stockholm IETF meeting is in order? The official BOF deadline is today,
but we could at least hold a Bar BOF.

> Please also identify if you have a specific interest
> area to consider for a potential new Atom WG.

I do not have specific interests at this time.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Erik Wilde <[email-masked]>
Date: Mon, 08 Jun 2009 19:24:15 -0700

hello nikunj.

> a new WG further. Please also identify if you have a specific interest 

i'd be interested in exploring the idea of a new WG. i think that more 
and more people are exploring Atom outside of its national habitat of 
blogging and newsfeeds, and it's essential for the continuing success of 
Atom to try to find a good balance of an increasingly diverse user base, 
and some consensus to avoid a partly overlapping and inconsistent set of 
extensions.

my specific areas of interest are geolocation, and how to make feeds 
queryable. both of these issues are currently more research areas than 
immediate specification goals (and GeoRSS for location is good enough 
for the moment, although some clarification or best practices document 
for it might be a good idea).

cheers,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

---

From: Peter Keane <[email-masked]>
Date: Mon, 8 Jun 2009 23:04:27 -0500

I am definitely interested.  Particular areas of interest are querying
operations, hierarchy, link extensions, feature discovery (atompub).
I am also quite interested in link and categories as first-class
addressable resources (although that's fairly off the map at this
point).

--peter

On Mon, Jun 8, 2009 at 3:41 PM, Nikunj R. Mehta<[email-masked]> 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:
>
> 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.
>
> Nikunj

---

From: James M Snell <[email-masked]>
Date: Mon, 08 Jun 2009 21:24:55 -0700

I think it's obvious at this point that I would be interested ;-)

The Atom feature, bidi, hierarchy and link extension mechanisms are of 
particular interest, as is the possible definition of a new profile 
media type parameter.

- James

---

From: "Myles, Stuart" <[email-masked]>
Date: Tue, 9 Jun 2009 09:36:57 -0400

Hello,

I'd be interested in participating in the proposed new WG.  My interest
areas would include hierarchy and metapublishing and in-line
representation.  But it would also extend to areas such as retracting
and expiring  previously published items (e.g. using ATOM to keep
distributed databases in synch).

Regards,

Stuart

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nikunj R. Mehta
Sent: Monday, June 08, 2009 4:42 PM
To: atom-syntax Syntax; atom-protocol Protocol
Subject: Exploring a new WG around Atom

Nikunj

The information contained in this communication is intended for the use
of the designated recipients named above. If the reader of this 
communication is not the intended recipient, you are hereby notified
that you have received this communication in error, and that any review,
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please 
notify The Associated Press immediately by telephone at +1-212-621-1898 
and delete this e-mail. Thank you.
[IP_US_DISC]
msk dccc60c6d2c3a6438f0cf467d9a4938

---

From: Martin Atkins <[email-masked]>
Date: Tue, 09 Jun 2009 11:05:04 -0700

> 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. Other extension elements may be 
added as siblings of the nested atom:entry element to allow extension 
specifications to still add additional elements here without altering 
the meaning of the inlining.

(the rel="related" here is arbitrary; this would ideally apply to all 
links of type application/atom+xml, regardless of which rel keyword is 
used.)

[1] http://activitystrea.ms/

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 09 Jun 2009 23:40:56 +0200

Martin Atkins a écrit :
> 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.
>
> -----------------
>
> 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.
>
> 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

---

From: Martin Atkins <[email-masked]>
Date: Tue, 09 Jun 2009 14:53:23 -0700

> really looks like it defeats the point of the atom:link element in the 

atom:content includes the content of the entry. In my example, atom:link 
points at some other entry that is related to this entry.

The purpose of atom:link here is to create a relationship between one 
entry and another; a non-authoritative subset of the target entry is 
included to allow consumers to avoid dereferencing the URL given in the 
href attribute if it is appropriate to do so.

Again, this is achieving a similar purpose to the child elements of 
atom:source, though in this case the href attribute of the containing 
link serves the purpose that a child link rel="self" does in atom:source.

(As an aside, had this been in the spec originally, atom:source could in 
theory have been specified as:

<link rel="source" type="application/atom+xml" href="...">
     <title>Martin's Blog</title>
     ...
</link>

)

(Reply-to is set to be only the atom-syntax list, since this discussion 
seems off-topic for atom-protocol; in retrospect, I should not have 
cross-posted in the first place.)

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Tue, 9 Jun 2009 15:13:01 -0700

>    <title>Martin's Blog</title>
This is similar to the realization that <span> and <div> along with  
@style and @class could do a lot of things that required a dozen or  
more pieces of markup in HTML.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Jun 2009 11:41:05 +0200

> area to consider for a potential new Atom WG.

4. Using the PATCH method (*) for partial updates to Atom entry documents.

BR, Julian

(*) <http://tools.ietf.org/html/draft-dusseault-http-patch-14>

---

From: "Lindsley Brett-ABL001" <[email-masked]>
Date: Fri, 12 Jun 2009 07:14:55 -0400

I am also interested in new WG activities. My interests are:

1. Intermediate aggregation.
2. Security, signatures, etc.
3. Usage rules, rights, etc.

Some of this may be outside the domain of Atom WG. I am interested in
using Atom for non-blogging publication applications.

Brett Lindsley
Motorola Applied Research & Technology Center

---

From: Colm Divilly <[email-masked]>
Date: Fri, 12 Jun 2009 15:12:18 +0100

I'm interested, specific areas of interest would be:

- meta-publishing
- query-feed discovery/navigation, i.e. discovering what queries can be 
applied to a collection, or even a mechanism for end-users to publish 
their own custom queries searching over AtomPub collection(s), and 
advertise those queries to other users.

Regards,
Colm Divilly