self and alternate links for entries
Hi, I'm building a tool (for Plone) at the moment that will publish any content as an Atom Entry by appending '/entry.xml' onto the URL. I had a question about declaring self and alternate links. Here are two options: 1: @rel=self,@type=application/xml+atom links to the Entry @rel=alternate, @hreflang, @type, links to the Content 2: @rel=self @hreflang, @type, links to the Content @rel=alternate, @type=application/xml+atom links to the Entry I couldn't find enough information in the RFC about which way to go. Which would you choose, and why? cheers Bill
Re: Atom namespace really not ending with / or # ?
Jan Algermissen wrote: Hi, is it really true that the Atom namespace is http://www.w3.org/2005/Atom ? Meaning that it is somewhat difficult to identify Atom elements with URIs: http://www.w3.org/2005/Atomauthor http://www.w3.org/2005/Atomconributor Was that simply a mistake or a design feature when Atom was standardized? Thinks I asked for a trailing '/' at some point; certainly for fnalising APP, I want a trailing '/'. cheers Bill
Re: PaceEntryMediatype
Bob Wyman wrote: The impact here is not just limited to APP implementations. If a new media type is defined, it will undoubtedly appear in other contexts as well. Given the current definition of the atom syntax, it is perfectly reasonable for an "aggregator" to treat a single entry as the semantic equivelant of a single-entry feed. I don't agree. atom:source is optional, and even then that does not cater for situations where entries have been annotated downstream. If a new media type is defined, such an application would end up having to be modified. That's not right... APP is not the only context within which Atom is used. What matters is whether atom:feed is the only context within which atom:entry is used, and/or whether atom:entry is an atom:feed in masquerade. After who knows how many posts and having gone back to the RFC, as I see it, neither of those is true or supported by the spec. There'll have to be another rationale presented for not spinning out a new media type. cheers Bill
Re: PaceEntryMediatype
Sylvain Hellegouarch wrote: I still don't understand the meaning of equivalence between an entry document and a single-entry-feed document. You don't need to; it doesn't exist. This is string theory for syndication. cheers Bill
feeds: what does atom:id denote?
Hi, I'm sending entries over XMPP packaged up as feeds. A question that has come up - should the feed's atom:id change each time a feed is sent, or should it remain the same for all feeds issued from a client? cheers Bill
Re: PaceEntryMediatype
Antone Roundy wrote: On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote: Following a link is not the same thing as subscribing to something. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Your agent then decides if subscribing to that resource is a good idea. To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes or . ... Maybe I want to monitor a single media resource; an Atom media entry would be an ideal thing to do so (I'd rather look at the meta data than at the media resource upon each poll). I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe. A few reasons why a user agent might want to be able to tell the difference between a link to a feed and a link to an entry beforehand is in order to: 1) be able to ignore the link to the entry (ie. not present it to the user) if the user agent doesn't handle entry documents (rather than presenting it as a "subscribe" link, only to have to say "sorry, it's not a feed" after the user tries to subscribe). 2) be able to say "subscribe" to links to feeds, and "monitor" links to entries (the user may not be interested in monitoring a single entry for changes--if they can't tell that that's what the link is for, they may end up needlessly doing so but think that they've added another feed to their subscription list). 3) to open an entry in an editing app. Datapoint: double clicking on an Atom Entry file in Ubuntu results in the following: [[[ The filename "LE1100_1254262_1_4E760C4E-36D9-065D-7AF7-FB168427888D_1081337005687.xml" indicates that this file is of type "XML document". The contents of the file indicate that the file is of type "Draft journal entry". If you open this file, the file might present a security risk to your system. Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for "Draft journal entry", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file. ]]] I believe this is because I had drivel installed at one point. Double clicking on an Atom Feed document opens it in Firefox. I'm kind of surprised by this, but thinking about it, you don't really write feeds, but you do write entries. cheers Bill
Re: PaceEntryMediatype
Mark Baker wrote: Isn't that just a case of people not implementing the whole spec though? Not really. The RFC defines the structure, not so much the interaction model around feeds (which is driven by UIs more than anything else, so I can buy into it being somewhat arbitrary) Or, are there applications which only process entry documents and not feed documents? Anything based on Atom Protocol will be making a distinction. cheers Bill
Re: PaceEntryMediatype
James M Snell wrote: When I process this entry, http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 I had problems subscribing to that entry in bloglines. Will somebody file a bug? cheers Bill
Re: PaceEntryMediatype
Mark Baker wrote: On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote: All I can go on is evidence of how folks are actually using 'em... and they ain't using 'em as aliases. :-) Ok, I'll take empirical evidence too 8-) Point the way ... Mark, since you introduced it, what's an "alias", exactly? cheers Bill
Re: PaceEntryMediatype
Mark Baker wrote: [..] it it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. One question and one observation. The question: how will this set a precedent? The observation: if we really want to avoid this problem (assuming there is a problem), then RDF was the answer, not a pretence of uniformity. cheers Bill
Re: PaceEntryMediatype
"Well it's all octets so in one sense the processing is the same." I have to agree with James. The right questions in my mind is this - how is processing an entry different from processing a feed with that and 42 entries? The idea that an entry is a degenerate feed is interesting, but unsubstantiated. Seriously, i'm not getting it. My experience is the opposite now, across 3 protocols; feeds are the odd men out (http needs them to deliver collections) and entries are not subsets of feeds. If there's real uniformity, I don't see it. To see it, I'd need to see that feeds and entries are closed under processing, and probably structurally isomorphic. We've enough field experience that suggests having entries and feeds sharing a media type is at best inconvenient. I only have to start thinking about how an APP collection handles partial update failures on a feed to think I need a dedicated media type for dealing with feeds. cheers Bill James M Snell wrote: Well, it's all XML parsing so in one sense the processing is the same. The key difference arises in how the various documents are used. In my experience, Atom Entry Documents are nearly the exclusive territory of APP Clients and push notification services (e.g. Atom over XMPP) while Feeds generally provide for the redistribution and indexing of entries. When I parse an entry document, there is no implied feed. - James Mark Baker wrote: Interesting, thanks. But serving different purposes doesn't necessitate a new media type. What's important is how the two types of documents are interpreted. How does your processing of an entry document differ from the processing of a feed containing (only) that same entry? If processing the entry is a subset of processing the feed, then you probably don't need a new media type. Mark. On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote: Mark Baker wrote: [snip] Yes, but more than that. An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. Hmm.. I understand what you're saying but I don't think I agree. In the APP implementations I've put together, Feed and Entry documents generally serve two entirely different purposes and are usually intended for two entirely different audiences. - James
Re: PaceEntryMediatype
A. Pagaltzis wrote: * Mark Baker <[EMAIL PROTECTED]> [2006-11-29 20:10]: An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. I disagree. There’s not much of a point in subscribing to an entry document, and APP servers will not accept POSTing feeds in place of entries. Well, it's kinda undefined - and this is circular - it's undefined because feeds and entries share a media-type. It would be useful to allow collections to accept non-atoms (har har). [EMAIL PROTECTED] expressed a need for batching, and I could really do with this for website/cms publishing. But because error handling semantics can be different for batches, it's tricky; some uniformity is lost if it's not thought out. cheers Bill
Re: PaceEntryMediatype
James M Snell wrote: Mark Baker wrote: [snip] Yes, but more than that. An entry document is, AFAICT, little more than shorthand for a feed with one entry, minus the feed-specific metadata. It's processing is a subset of feed processing. If the processing or content model of entry is extended, it applies to both feed documents and entry documents. Hmm.. I understand what you're saying but I don't think I agree. In the APP implementations I've put together, Feed and Entry documents generally serve two entirely different purposes and are usually intended for two entirely different audiences. Same here. Feeds are collections; saying that entries are implicit collections is something I don't grasp - it's too abstract. [The only time I've been able to treat feeds and entries uniformly is feeding RSS1.0 into a RDF aware system.] cheers Bill
Re: PaceEntryMediatype
James M Snell wrote: Create a new media type for Atom Entry Documents: application/atomentry+xml +0 cheers Bill
Re: feed id's and paged/archive feeds
Mark Nottingham wrote: Sorry, this got lost in my inbox... I think they do, although the draft is silent on it. This is one of those areas where it would have been really nice if the WG had agreed to take on FH as part of the core, rather than extension; there are lots of little ambiguities like this as a result. I doubt that would clear things up. This is a HTTP thing, not an Atom thing. My thinking on this matter is that Atom feeds aren't resources, they're representations. Specifically they're a hack/optimisation to deal model collections/iterators for HTTP. Anyone who really cares should try sending Atom over XMPP or email; it'll be clear enough that entrys matter, but feeds don't. [An RDF modelling execise by the WG would have made it clear that feeds are problematic entities, but we'd probably be going into last call sometime the new year as a result.] cheers Bill
Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]
A. Pagaltzis wrote: I think given the above background you'll agree that the intent of the document is pretty coherent. I couldn't tell whether new Atom extensions are foreign markup, or something else to be dealt with under wrt being a "forward-compatible" friendly consumer. It's kind of circular. In short, I guessed and you told me I was wrong. cheers Bill
Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]
Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up any
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined
in XHTML.
Thoughts?
"Foreign markup" is ambiguous.
[[[
Markup from other vocabularies ("foreign markup") can be used in an
Atom Document.
]]]
[[[
For the purposes of this discussion, unrecognized markup from the Atom
vocabulary will be considered "foreign markup".
]]]
Perhaps this is what's intended by those statements:
"""
Markup not defined in this document is called "foreign markup"
"""
I don't think the document can forward to proposed without
clarification. Also, "forward-compatible" is mentioned, but not defined
- it's not possible to make a safe assumption on what it means, since
it's relative to whatever "foreign markup" is. I assume "unrecognized"
and "unknown" are synonymous.
cheers
Bill
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.
