Re: New Pace: PaceAggregationInSeparateSpec
I have heard interesting arguments It's all about the Entries, stupid! that made the opposite assessment: namely that the entries are what is important, and that what feed an Entry is part of, is a accident of life. The idea there is that Entries are the stand alone entities. They can be made to be part of any feed whatsoever. A feed in this conceptualization, is a little like a search engine result listing where the pages they refer to are like entries (notice that search engine results pages are just a type of web page too). Which feed your entry appears in will depend very much on the type of query the user of the search engine made. OK, I can buy that, as long as that is indeed how things are supposed to be defined. Note, however, that the Atom syntax spec focuses on feeds as resources and that entries just happen to be contained in feeds. e.g. from Section 1: Atom is an XML-based document format which describes lists of related information known as feeds. Feeds are composed of a number of items, known as entries, each with an extensible set of attached metadata. If the assertion that the entries are the standalone entities is correct, then the text in the spec needs to be changed to reflect that assertion. Granting the assumption that the entries are the standalone entities and feeds are merely just a convenient container for entries, the identification of containing parent-feed becomes less important. The need to identify where the entity came from, however, obviously still remains.. although not necessarily as a core requirement. Back to the original point about HeadInEntry: HeadInEntry is not required to achieve the origin/container identification, regardless of whether or not origin/container identification should be part of the core. If there are no other reasons why HeadInEntry should remain in the core, then by all means, rip that sucker out of there. PaceAggregationInSeparateSpec by no means locks it in place. Of course if an entry has a tag such as origin (which used to be on the table) then the entry it points to would be part of the metadata of the entry and so be a legitimate way of creating special selection of entries. Henry Story -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: PaceProfile - new
Absolutely, there would be a core default profile defined in the Atom syntax spec. @profiles=core syndication @profiles=core blog, etc. On Fri, 4 Feb 2005 15:19:59 -0800, Mark Nottingham [EMAIL PROTECTED] wrote: On Feb 4, 2005, at 3:13 PM, James M Snell wrote: If a profile is indicated that the UA does not understand, the UA could safely ignore the profile and just work off the minimally required core metadata elements. Ah, that's the rub; I'm trying to say that that set of 'core' elements is, in and of itself, a profile. -- Mark Nottingham http://www.mnot.net/ -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: Thinking ahead: Atom Extension Proposals on the Wiki?
I will start working on the template this week and will get something posted by the weekend. On Thu, 3 Feb 2005 11:46:14 +0100, Danny Ayers [EMAIL PROTECTED] wrote: On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby [EMAIL PROTECTED] wrote: James Snell wrote: I'm just thinking ahead a bit on this, but I am wondering if it would be possible for those of us interested in proposing non-core extensions to Atom to use the Wiki as the forum for sharing proposals for extensions once the core syntax has been finalized? Go4it. Yep, good idea. I can see a few in the intray: ipaddress/host (for anon posts to Wikis etc); the ENT (Easy News Topics) RSS 2.0 extension is in the process of being revised, and an Atom-compatible syntax is planned; Yahoo's media object extension. A Wiki template would be nice - have you started writing anything up yet, James? Cheers, Danny. -- http://dannyayers.com -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: CAP over Atom (PubSub Common Alerting Protocol Earthquake Feeds...)
This is excellent to see. I'm glad to see that you were not afraid to break the syntax rules to get things started. :-) The format looks good. On Thu, 3 Feb 2005 21:50:51 -0500, Bob Wyman [EMAIL PROTECTED] wrote: At PubSub.com, we've started generating CAP over Atom files. By this I mean we're publishing using Atom files to encapsulate a stream of message which are encoded using the CAP (Common Alerting Protocol) format. See: http://www.oasis-open.org/committees/download.php/6334/oasis-200402-cap-core-1.0.pdf . Because CAP is an XML format, we're using atom:content elements with type=text/xml. In order to ensure that there is something for aggregators to display if they don't understand CAP, we're generating atom:summary elements that contain a textual summary of the CAP message which is in the atom:content. My hope is that aggregator developers will commonly implement a pattern of displaying the atom:summary rather then the atom:content in cases where they don't understand the XML type of the content element. I would appreciate any review comments that you might be able to make on our use of Atom in this application. For a sample Atom feed containing CAP messages which describe recent earthquakes, please see: http://atom.pubsub.com/c0/b8/bd62e8e48058c0425193b37ea6.xml A sample atom:entry extracted from this Atom Feed is below: entry ps:nodeID/pubsub/topics/301/ps:nodeID title![CDATA[ Earthquake: M 1.6 (D) NORTHERN CALIFORNIA 2005-02-04T02:00:43.100Z ]]/title issued2005-02-03T21:04:42-05:00/issued modified2005-02-03T21:04:42-05:00/modified idtag:pubsub.com,2005:CAP:nc51156375/id link rel='alternate' type='text/html' href='http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm'/ summaryAn earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a computer-generated message and should not be considered authoritative.) /summary content type='text/xml' alert xmlns=http://www.incident.com/cap/1.0; identifiernc51156375/identifier sender[EMAIL PROTECTED]/sender sent2005-02-03T21:04:42-05:00/sent statusTest/status msgTypeAlert/msgType scopePublic/scope incidentsnc51156375/incidents info categoryGeo/category eventEarthquake/event urgencyUnknown/urgency severityUnknown/severity certaintyUnknown/certainty senderNamePubsub Earthquake Service/senderName headlineEarthquake: M 1.6 (D) NORTHERN CALIFORNIA 2005-02-04T02:00:43.100Z/headline descriptionAn earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a computer-generated message and should not be considered authoritative.) /description webhttp://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm/web parameterEventID=nc51156375/parameter parameterVersion=1/parameter parameterMagnitude=1.6 MD/parameter parameterDepth=2 km/parameter parameterVerified=N/parameter area areaDesc2 km depth at latitude 38.8168, longitude -122.7915 at location: NORTHERN CALIFORNIA/areaDesc circle38.8168,-122.7915 0/circle /area /info /alert /content /entry Note: I am aware of a few issues with our current use of Atom: 1. We often issue files that contain more than one entry with the same atom:id. For instance, you might have a message which is followed in the file by an update concerning the same incident or a Cancel message for the event. I know this is a violation of the specification. We will eventually stop doing this Please bear with us. 2. We currently don't provide an atom:link element with rel=alternate when we insert a CAP Cancel message into the feed. This is, of course, because we have no page to point to for a deleted or cancelled event. In the future, we'll consider having all such Cancel messages point to a common static help page which explains a variety of reasons why a message may have been deleted. 3. If you view the Atom feed in a web browser, the result may not be terribly pleasing We're still working on the style sheet. Please pay attention only to the source of the feed (i.e. do View Source). This service compliments the Earthquake service that I recently mentioned on this list. We will be publishing both raw Earthquake messages/feeds as well as CAP messages/feed in the future. These two formats are targeted at different audiences. Your comments and/or suggestions would be appreciated. bob wyman -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: On organization and abstraction
On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman [EMAIL PROTECTED] wrote: Tim Bray wrote: So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) -1... PaceAggregationDocument does not seem to me to add much benefit for all the costs that it entails. I'm particularly concerned that adding a new type of root document aggregation is likely to add enough to the complexity of Atom that only a subset of developers will actually get around to supporting this third type of document -- a type which doesn't exist in the simple RSS aggregators that exist today. +1 to this -1. The aggregation element is not a necessary part of the core and adds complexity without adding *significant* benefit to the core. 2. As mentioned before, the introduction of a new level of abstraction (i.e. aggregation) is likely to scare off a good proportion of the aggregator developers. Current aggregators don't have the concept of aggregation in them. Thus, new design and new architecture will be required to address this Pace. On the other hand, staying with HeadInEntry is much more gentle on the existing systems and thus much more likely to be useful in the field. This is precisely why I don't think this belongs in the core. For those who need this type of functionality, the opportunity exists for them to create a separate Internet-Draft that describes how to aggregate feeds -- without adding complexity to the core syntax by introducing elements that the vast majority of users will *likely* never use. (I obviously base this assumption on the reasoning that most Atom users will use it as a drop in replacement for RSS). 3. Since there will be at least some subset of aggregators that won't understand the aggregation thing, it is likely that we'll have a chicken and egg problem. No one will produce aggregation documents since not everyone supports them. Thus, no one will support them since no one generates them. Well, I wouldn't go this far. There is obviously a requirement for it for some folks and those folks are likely to make good use of it. What I would rather see the WG do is take a minimalist approach with this. Right now, I see aggregated feeds falling into that limited 20% of use cases that could be done, but aren't necessarily critical to be done. Aggregation could be defined as an extension to Atom, and later, based on an analysis of its implementation over time, can be merged into the Atom core if deemed appropriate. Merging it into the core now does not guarantee that its adoption and use will be any greater than if it were done as an extension. 4. Massive changes need to be made to the specification when we don't have a great deal of time left before we're supposed to be doing a Last Call. This is dangerous. +1. Big +1. -1. I really don't see any compelling benefit in exchange for the tremendous risk and cost of accepting PaceAggregationDocument and dropping HeadInEntry. Let's avoid adding to the levels of abstraction here and keep it simple. We should have feeds and entries -- nothing else. One point, HeadInEntry solves the problem of having a standalone Atom Entry document be able to reference a feed of which it is a part. Unless I'm misreading something, if PaceAggregationDocument gets rid of the ability to put Head elements in the entry, don't we lose this capability? (this is something that is important, for instance, in my Atom Notification Protocol proposal) I would like Atom to be more like Visual Basic and less like Lisp. As an ex-Visual Basic Product Manager, I think this would be a good idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to reader: Visual Basic .NET is .NOT Visual Basic... Aargh! VB... it burns! (sorry, temporary flashback to past hell. Sorry Bob, VB was an excellent product, I just was forced to be witness to some extremely bad uses of it. Nightmares, I tell you, nightmares!) bob wyman -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: PaceRemoveInfoAndHost
+1 On Thu, 3 Feb 2005 20:24:06 -0800, Mark Nottingham [EMAIL PROTECTED] wrote: +1 Welcome to the club :) On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote: http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost Proposal --- Remove atom:info and atom:host from The Atom Syndication Format. Remove atom:host --- No one seems to like the atom:host element. It doesn't do what its original proponents wanted and many of its detractors still oppose it. Design by committee at its worst. Remove atom:info --- Back when we were arguing about IETF vs. W3C, mnot said in the IETF, it's easier to shut down a solo raving loony. In the threads on atom:info, it seems I am playing the role of solo raving loony. So, let's have the process take over. Robert Sayre -- Mark Nottingham http://www.mnot.net/ -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: Organization Use Cases (was: Re: Format spec vs Protocol spec)
Potential solutions that occur to me: 1. Ignore the problem 2. PaceEntriesElement could handle this 3. PaceFeedRecursive could handle this 4. PaceAtomHeadInEntry could handle this 5. PaceAggregationDocument could handle this I honestly can't say which I prefer. Would anyone like to try to put together examples of the solution in #2 through #5 so that we can consider the alternatives? 6. Handle the problem in a non-core extension. The core Atom syntax does not have to deal with all these cases as long as it does not interfere with someones ability to deal with cases later on. Get version one out the door. Get folks to start implementing it. Start writing up extensions. Get folks to implement those extensions. Figure out which extensions are Really Useful. Add those Really Useful Extensions to the core later. -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
New Pace: PaceAggregationInSeparateSpec
Figured I would formalize what I've been evangelizing the past couple of days. http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec == Abstract == Defer the definition of solutions for aggregated feeds to a separate Internet-Draft that is not a part of the Atom core syntax specification. == Status == Proposed (by [JamesSnell]) == Rationale == Aggregated feeds, while important, are currently not supported by the existing RSS mechanisms and are relatively rare in comparison to their single feed cousins. Given the guidelines for proposals set forth in this Wiki, this alone would justify moving the aggregation stuff off to a separate document, at least for now. * The 80/20 rule: If a feature will only be used by a small number of people, and will create extra work and headaches for everyone else, it probably doesn't belong in the core spec. * Pick stuff that's already been proven to work and be interoperable, and writing it down in a clean, clear way * Keep it simple: The simplest thing that can possibly work tends to be preferred over more complex solutions. I absolutely acknowledge that there are a subset of folks for whom aggregated feeds are very important. But this is a subset. Let that subset document their ideas in a separate Internet-Draft; let them implement those ideas and build momentum for them; then let us later come back later and discuss the merits of merging those ideas into the core. == Proposal == (see abstract) == Impacts == Defers PageAggregationDocument and PageFeedRecursive to a separate Internet-Draft * Lets Atom 1.0 get out the door faster. * Lets folks gain valuable implementation experience before committing to major changes to the Atom core spec to support what is currently an edge case * Keeps the Atom core simple == Notes == -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: New Pace: PaceAggregationInSeparateSpec
On Fri, 04 Feb 2005 02:14:14 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Antone Roundy wrote: leaving things as they are and deferring deciding how to handle aggregation would irreversibly enshrine HeadInEntry into the format, which all of the current organizational proposals are trying to replace. That's right. Besides, HeadInEntry is trivial to do as an extension, so there's no reason to leave it in. I agree with this so long as there is a core mechanism that allows a standalone entry to identify the feed to which it belongs. That mechanism does not have to be atom:head, but it does need to be part of the core. Robert Sayre -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: PaceCollection
-1. A name change of the top level element accomplishes nothing.
On Thu, 03 Feb 2005 16:55:35 +1100, Eric Scheid
[EMAIL PROTECTED] wrote:
http://intertwingly.net/wiki/pie/PaceCollection
== Abstract ==
Rename the top level element name for the atom document format which holds a
collection of entries, to better communicate it's collection nature, and
more easily allow non-feed collections.
== Status ==
Open
== Related and Conflicting Proposals ==
none
== Rationale ==
The term feed has generally held the special meaning of the collection of
entries which were recently published, and into which new entries will also
be published, with older entries being removed sliding window style (or
something like that)
Which has meant it has been a pain to refer to Atom Feed Documents which
don't obey that semantic, instead being (say) an archive of all posts within
a specific period of time (eg. June 2004). A given resource (eg. the June
2004 archive) could be said to be both an Atom Feed document, but also
''not'' be a feed. Confusing.
Atom Feed Documents are properly collections, of which feeds are just one
semantic. Other semantics for Atom Collection Documents include archives,
directory, comments, trackbacks, pings, parts, versions, and so
on.
== Proposal ==
Rename the top level element for Atom Feed Documents to atom:collection,
and rename Atom Feed Document to Atom Collection Document.
{{{
no spec text -- this is really just a job for the editor, i hope.
*s/atom:feed/atom:collection/
*s/Atom Feed Document/Atom Collection Document/
}}}
== Impacts ==
none. it's just a name change.
== Notes ==
CategoryProposals
--
- James Snell
http://www.snellspace.com
[EMAIL PROTECTED]
Re: Call for final Paces for consideration: deadline imminent
+1 Eric. sub-feeds can easily be nested by reference using the existing link mechanism as opposed to nesting by containment. Overall this would be a cleaner model and would be easier on bandwidth by allowing nested feeds to be broken up over several documents rather than stuffed all into a single document. On Thu, 03 Feb 2005 16:21:42 +1100, Eric Scheid [EMAIL PROTECTED] wrote: On 3/2/05 4:01 PM, Robert Sayre [EMAIL PROTECTED] wrote: 4.) Atom sucks at blogs with comments or trackbacks 5.) Atom sucks at anything with a representation of its own and collection membership link href=... type=application/atom+xml rel=comments / link href=... type=application/atom+xml rel=trackbacks / link href=... type=application/atom+xml rel=parts / e. -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent)
Comments below.. On Thu, 03 Feb 2005 17:27:33 +1100, Eric Scheid [EMAIL PROTECTED] wrote: On 3/2/05 5:09 PM, James Snell [EMAIL PROTECTED] wrote: What is the model for archiving with Atom? One or more distinct Atom feeds that each contain a collection of old entries? If so, what we need then is a just container for feeds. One that encapsulates by reference rather than by direct containment. Perhaps a top level document like the following would be sufficient?) !-- archive-index.xml -- index archive href=2001/archive-feed.atom titleArchive Title/title /archive Your example format doesn't include dates for when the referenced items were last updated, nor unique IDs for disambiguation, etc etc ... why not instead: feed head titleThe 2001 Archive of My Big Fat Fenugreek Blog/title [...] /head entry titleJanuary 2001 Archive/title summary208 posts over 19 days/summary link href=... type=application/atom+xml rel=alternate / [...] /entry entry titleFebruary 2001 Archive/title summary311 posts over 23 days/summary link href=... type=application/atom+xml rel=alternate / [...] /entry /feed This is better. I guess I just hadn't grok'd the idea of using entries to reference feeds, but now that I see the angle brackets I get it. (perhaps I just need some coffee). As long as it is legal for an alternate link to reference a feed document, this works perfectly. I like the containment-by-reference approach. Best of all, this could be accomplished without requiring any changes to the existing core.. Just a single new @rel value for the link element in an atom feed head can then be created that points to this archive index document. feed head link rel=archive type=application/atom+xml href=... / /head [...] /feed this is exactly what I had in mind with PaceCollections. Well, from your Pace: Atom Feed Documents are properly collections, of which feeds are just one semantic. Other semantics for Atom Collection Documents include archives, directory, comments, trackbacks, pings, parts, versions, and so on. If we define a feed as a collection of entries, archives, directories, comments, trackbacks, pings, parts, versions, and so forth, then the name feed is descriptive enough to get the point across. I'm not sure I follow the connection between PaceCollection and the archive @rel attribute. Did I miss something? e. -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
ServiceElement and other matters
Ok, so I'm an Atom end-user who has been monitoring the fringes of the effort to define the spec and am now spending some time going through the near-finished product to see what issues I can spot. That said, likely just as most potential atom-end-users, I am not aware of the full history of the various conversations and debates that may have gone on previously regarding any single part of the spec. In reading through the spec, several things stick out: 1. Service Construct. While I understand what the Service Construct is trying to do, and I agree that it is needed, it does not seem to me to be something that rightfully belongs in the core Atom syntax. Rather, it seems better placed as an Atom syntax extension introduced by the Protocol specification. The rationale is simple: The Protocol spec should deal with all service related issues, including any extensions to the core that are necessary to communicate protocol related information. If I were putting this stuff together, I would move the Service Construct to the protocol spec. 2. Entry id's. Ok, so they are supposed to be universally unique. That's all good and fine. But what if... hypothetically... my Atom reader gets two copies of the same Entry with different metadata. They are the same entry because they have the same id. One of the versions of the entry differs from the other in that some feed aggregator somewhere added some additional pieces of metadata to it. Do I: a) silently reject one of the entries, b) merge the metadata of the two entry instances into a single logical entry, c) throw up on the user. Case in point where this might be an issue: Suppose an entry in a feed that references a standalone entry document for the same entry. !-- feed.xml -- feed entry titleMy Entry/title iduri:abc/id link rel=alternate href=entry.xml type=application/atom+xml / /entry /feed !-- entry.xml -- entry iduri:abc/id contentHello There/content /entry Is this legal? If it is, how should clients handle this situation? Do the two separate entry elements merge to form a single logical entry or does one replace the other? 3. I know this has been discussed elsewhere because I've seen a couple of recent posts about it. The version attribute just seems hokey. It doesn't add any value beyond what the XML namespace already provides. Just one guys opinion. Take it for what it's worth. 4. What the heck is an introspection document? I actually do know what it is, but the current doc doesn't say. This needs to be fleshed out obviously. Of course, if #1 above is addressed, this ceases to be a problem. :-) This is what I came up with on my first full read through of the -05 draft. Maybe more later. -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Atom Notification Protocol Update
I have just submitted an update to the Atom Notification Protocol draft that will hopefully be published in a day or so. I have attached the draft for review. Summary of changes: * Rather than POSTing atom:feed elements to indicate an updated feed, atom:head elements are POSTed. * Eliminated the NotificationURI location mechanisms. NotificationURI's will be located in some application specific manner. It didn't make sense at this point in time to define a common mechanism. * Head-In-Entry has been marked as a SHOULD * Expanded treatment of HTTP response codes and HTTP methods To reiterate the prior discussion that happened on this, I am not intending this as a competitor to Atom-XMPP. I think both have their place and both contribute to the General Good. I would appreciate folks giving this a look over and offering any comments you may have. -- - James Snell http://www.snellspace.com [EMAIL PROTECTED] Network Working Group J. Snell Internet-Draft January 31, 2005 Expires: August 1, 2005 The Atom Notification Protocol draft-snell-atompub-notification-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 1, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This memo presents a protocol for posting notifications of new or updated content using a combination of the Atom Syndication Format and HTTP POSTs. SnellExpires August 1, 2005 [Page 1] Internet-Draft The Atom Notification Protocol January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Atom Notification Protocol Model . . . . . . . . . . . . . 3 3. Functional Specification . . . . . . . . . . . . . . . . . . . 3 3.1 NotificationURI . . . . . . . . . . . . . . . . . . . . . 3 3.1.1 Locating the NotificationURI . . . . . . . . . . . . . 4 3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 SnellExpires August 1, 2005 [Page 2] Internet-Draft The Atom Notification Protocol January 2005 1. Introduction The Atom Notification Protocol is an application-level protocol for posting notification of new or updated content using HTTP and the Atom Syndication Format. 1.1 Notational Conventions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [1]. 1.2 Terminology Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this case, the fragment is a single 'entry' element and all its child elements. Each Atom Entry describes a single Web resource, providing metadata and optionally a textual representation of that resource. Atom Head: atom:head elements are used within the Atom Syndication Format as children of both the atom:feed and atom:entry elements to provide information descriptive of the feed. NotificationURI: A HTTP URI that is used to receive notifications about new or updated Atom entries. 2. The Atom Notification Protocol Model The Atom Notification Protocol has been designed to complement the Atom Publishing Protocol
Re: Please Review: Dissemination of Earthquake / Tsunami data via Atom
What I'm wondering here is whether or not a retracted / or retracts / element could be used for this purpose. The retracted / element would be used within an entry to indicate that the entry has been retracted. The retracts / element would be used within a second entry to identify it as a retraction for some preceding entry. For example: entry ... idurn:my-entry-1/id retrated by=urn:my-entry-22005-01-07T12:00:00-8:00/retracted ... /entry entry ... idurn:my-entry-2/id retractsurn:my-entry-1/retracts /entry The retraction elements can be defined externally to the Atom core. On Sat, 15 Jan 2005 18:00:39 +, Eric Brunner-Williams in Portland Maine [EMAIL PROTECTED] wrote: um... cancel messages? look, errors or state change repudiation is latent in all reported state. why un-write when you can later-write? -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Re: Atom Notification Protocol Published
On Sat, 18 Dec 2004 02:34:18 -0500, Bob Wyman [EMAIL PROTECTED] wrote: James Snell wrote: For XMPP-enabled environments, draft-saintandre-atompub-notify-01 is Goodness. Not every environment is going to be XMPP-enabled. Just about everyone is HTTP POST enabled. I think that focusing on the differences between XMPP and HTTP POST is not really useful in this discussion. Each transport protocol has advantages in one or another environment. What's interesting is not the transport protocol but rather the payload that is transported! (i.e. The slogan It's about the Entries, Stupid! applies in this case.) You're absolutely correct of course. I think the important point is that there probably isn't a great deal of justification for having different payload formats for these protocols. If we strip away the XMPP and HTTP transport wrappers, overhead, etc. I don't see any reason why it would be useful to have different messages. Honestly I do not know enough about the use cases of the XMPP based mechanism to pass judgement on their payload formats. What I can say, however, is that for the Atom Notification Protocol (ANP) approach, nothing more than the entry and feed elements are necessary. If we can get some alignment between this and the XMPP stuff, wonderful, but I'd very much like to avoid adding anything else to the ANP payloads bob wyman -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
Potential Issue: Section 4.2.2 atom:link
Reading through the current draft I note that in section 4.2.2 referring to the atom:link element, there is the following restriction: atom:head elements MUST NOT contain more than one atom:link element with a rel attribute value of alternate that has the same type attribute value. My question is: what if I want to offer two alternates of the same type that use different languages? e.g. atom:link rel=alternate type=text/html hreflang=en href=... / atom:link rel=alternate type=text/html hreflang=fr href=... / I'm not sure if this is an unreasonable thing to do or not but it did strike me as being potentially problematic. -- - James Snell [EMAIL PROTECTED]
