Re: URGENT: Remove atom:updated ordering requirement?
+1 to removing the MUST. +0 to changing it to SHOULD. Tim Bray wrote: Please see the dialogue below. (Eric's point seems plausible to me; personally I'd be inclined to a +1.) Can we have some feedback from the WG ASAP? We want to take protocol-11 to the IETF. -Tim On Sep 26, 2006, at 4:59 PM, Eric Scheid wrote: On 27/9/06 8:15 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: PaceAppEdited: Lots of discussion. There seems universal support for the utility of an app:edited element, and an assertion that entry members SHOULD contain one. On the other hand, every discussion of sort order has spiraled instantly into a rat-hole. Conclusion. PaceAppEdited is accepted, in part. The second part of the proposal, defining the app:edited element, is ACCEPTED. The first part, imposing a requirement on the sort order of collections, clearly does not have consensus support. There also seems to be universal support for the notion that collection feeds could be sorted by something other than what's currently in the spec. The spec currently not only says collections are to be sorted by atom:updated, but because of the MUST it also says it MUST NOT be sorted by anything *else*, which is a problem. Section 10.0 ¶ 2 says this: The entries in the returned Atom Feed MUST be ordered by their "atom:updated" property, with the most recently updated entries coming first in the document order. Clients SHOULD be constructed in consideration of the fact that changes which do not alter the atom:updated value of an entry will not affect the position of the entry in a Collection. We need to either strike that entire paragraph, or at the very least make that MUST into a SHOULD. I say +1 to s/MUST/SHOULD/ e.
Re: Atom Export
I haven't done much deep thinking about this proposal yet, but the one thing that concerns me are the non-atom resources that go along with the entries. When I export from a blog, I want to be able to export everything in a single operation. I've been stewing lately over the possibility of doing something similar to this but wrapping the atom documents and associated resources into a zip. A single master atom feed would provide an index of the archive, with individual entries either contained in that index feed or as separate entry documents (modeled loosely after the distinction app makes between the collection feed and individual editable entries. - James Bill de hOra wrote: > > Alastair Rankine wrote: >> >> Hello Atom folks, >> >> Here is a proposal for an Atom-derived format for exporting of content. >> >> The problem I'm trying to solve is that of migration from one >> authoring system (eg blogging engine) to another. Atom is highly >> suited to this task. >> >> The full problem statement, and the reasons for basing the solution on >> Atom, are all described in the proposal published here: >> >> http://girtby.net/offerings/atomexport >> >> There is no implementation yet. >> >> I look forward to your comments on this document. > > > Very quickly (I'm overloaded atm) - this is excellent. > > I've been looking at using Atom Entries for roundtripping/backup and > interchange, especially in CMSes, for some time. The ultimate dump > format in terms of expressiveness is RDF/XML, but it can be complicated. > Atom offers a lot of value with comparative simplicity largely because > atom:id can survive across systems*, but also because the flat format of > entries maps well onto relational data (it's particularly good for > dumping metadata). One hard problem is in usefully storing and indexing > received foreign markup. > > cheers > Bill > > * that said, for "consumer" data, the APP leans towards, or least > allows, rewriting of atom:ids due to trust issues. > >
Re: Atom Export
Alastair Rankine wrote: Hello Atom folks, Here is a proposal for an Atom-derived format for exporting of content. The problem I'm trying to solve is that of migration from one authoring system (eg blogging engine) to another. Atom is highly suited to this task. The full problem statement, and the reasons for basing the solution on Atom, are all described in the proposal published here: http://girtby.net/offerings/atomexport There is no implementation yet. I look forward to your comments on this document. Very quickly (I'm overloaded atm) - this is excellent. I've been looking at using Atom Entries for roundtripping/backup and interchange, especially in CMSes, for some time. The ultimate dump format in terms of expressiveness is RDF/XML, but it can be complicated. Atom offers a lot of value with comparative simplicity largely because atom:id can survive across systems*, but also because the flat format of entries maps well onto relational data (it's particularly good for dumping metadata). One hard problem is in usefully storing and indexing received foreign markup. cheers Bill * that said, for "consumer" data, the APP leans towards, or least allows, rewriting of atom:ids due to trust issues.
URGENT: Remove atom:updated ordering requirement?
Please see the dialogue below. (Eric's point seems plausible to me; personally I'd be inclined to a +1.) Can we have some feedback from the WG ASAP? We want to take protocol-11 to the IETF. -Tim On Sep 26, 2006, at 4:59 PM, Eric Scheid wrote: On 27/9/06 8:15 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote: PaceAppEdited: Lots of discussion. There seems universal support for the utility of an app:edited element, and an assertion that entry members SHOULD contain one. On the other hand, every discussion of sort order has spiraled instantly into a rat-hole. Conclusion. PaceAppEdited is accepted, in part. The second part of the proposal, defining the app:edited element, is ACCEPTED. The first part, imposing a requirement on the sort order of collections, clearly does not have consensus support. There also seems to be universal support for the notion that collection feeds could be sorted by something other than what's currently in the spec. The spec currently not only says collections are to be sorted by atom:updated, but because of the MUST it also says it MUST NOT be sorted by anything *else*, which is a problem. Section 10.0 ¶ 2 says this: The entries in the returned Atom Feed MUST be ordered by their "atom:updated" property, with the most recently updated entries coming first in the document order. Clients SHOULD be constructed in consideration of the fact that changes which do not alter the atom:updated value of an entry will not affect the position of the entry in a Collection. We need to either strike that entire paragraph, or at the very least make that MUST into a SHOULD. I say +1 to s/MUST/SHOULD/ e.
Atom Export
Hello Atom folks, Here is a proposal for an Atom-derived format for exporting of content. The problem I'm trying to solve is that of migration from one authoring system (eg blogging engine) to another. Atom is highly suited to this task. The full problem statement, and the reasons for basing the solution on Atom, are all described in the proposal published here: http://girtby.net/offerings/atomexport There is no implementation yet. I look forward to your comments on this document.
