Re: PaceEntryMediatype
Bob Wyman wrote: On 12/10/06, Eric Scheid [EMAIL PROTECTED] wrote: The only danger [of defining a new media type] is if someone has implemented APP per the moving target which is Draft-[n++] ... they should revise their test implementations as the draft updates, and certainly update once it reaches RFC status, so no sympathies there. 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. 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. I still don't understand the meaning of equivalence between an entry document and a single-entry-feed document. I have read your other message and I'm still nowhere near an understanding of it. In fine if you accept that an entry document is just equivalent to a single-entry-feed you have to detail precisely how this equivalence takes place and can be measured. Is it based on the atom:id? If yes is it on the atom:id of the entry or the feed? Is it based on its metadata? Again which ones since an entry embedded in a feed can overwrite the feed metadata. You should also explain why we have entry document at all if they are equivalent to single-entry-feed ones. Moreover you claim that it's going to break implementations. Which ones? How? Why? Can't those applications be updated? Why shouldn't APP be set straight because of those applications? There is a large feeling on the WG that there could be a use for distinction at the message level. We all acknowledge that could be disruptive but I don't think I can agree that it would bring down a all set of applications. You say those in favor haven't brought good use cases but neither have you. - Sylvain
Reviving Atom Export
So I got a bit distracted for a bit. Here's what we were talking about. ### What is it? Atom Export is a proposal for a standard/convention/something for the export of content from a CMS (think blogging engine) in a format that is similar to other Atom standards. The assumption here is that the content being exported is a good fit for Atom. I believe this to be the case (hence discussing it on this list) but it is not established yet. More rationale, and initial attempt, here: http://girtby.net/articles/ 2006/08/14/towards-a-common-blog-export-format ### Where did we get up to? We have a list of requirements for the export format, specifically the data from a typical blogging engine that should be included in the export. We also had identified some preliminary issues with representing the content in an Atom-based document format. Lastly we had clarified some scope, namely that the primary use case should be for migrating from one content engine to another, and not necessarily for backup purposes within a single application. ### What data is to be represented by this? Here is a list of data to be included in the export. For convenience a blog engine is assumed, although other compatible CMSs may implement this as well: 1. Complete list of authors defined. For each author: 1. Name 2. URI 3. email 2. Complete list of categories defined: 1. Name 2. URI 3. All articles. For each article: 1. Source text 2. All the relevant metadata from the Atom spec, namely: author, ID, published, rights, title, updated, summary, categories 3. Some other metadata: draft status, syntax of source 4. All comments and trackbacks. For each comment or trackback: 1. Source text 2. Atom spec metadata: author, ID, title, published, summary, avatar? 3. Additional metadata: pointer to parent article or comment (ie in-reply-to) 5. All Owned media. For each media object: 1. URI 2. MIME type 3. Binary data ### What are the issues identified so far? Briefly: * It was felt that the inclusion of binary media objects warrants the use of a binary archive format. The issue of how to organise the content within the archive file is unresolved. * There was some discussion about the inclusion of generated text, specifically HTML generated from the source text. It is redundant but may be useful. ### What now? I think the best way to proceed is to propose a fresh mapping of the above data requirements to Atom-derived constructs. I already had a go at this previously, but I think it might be better to start afresh. This time I'd like to try an approach based around the concepts introduced in APP, particularly that of collections, which look like a good fit for items 3,4, and 5 above.
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: Atom Entry Documents
On Sun, 10 Dec 2006 20:19:53 +0100, James M Snell [EMAIL PROTECTED] wrote: Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed +1. I believe that a type parameter allows more smoothly for new types to be introduced in the future, plus it more clearly states that it is an Atom resource than a completely new MIME type. All in my humble opinion of course. This is just a matter of taste, afaict. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry Documents
Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed +1 IMO, new optional type parameters make more sense. Judy- On 12/10/06, James M Snell [EMAIL PROTECTED] wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. The only question is whether or not to use a new media type or an optional type param. I'm going to write up an I-D this week. Please let me know which of the two approaches below y'all prefer... Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed Option B) New Entry media type application/atom.entry+xml - James
Re: Atom Entry Documents
On Dec 10, 2006, at 11:19 AM, James M Snell wrote: Option B) New Entry media type application/atom.entry+xml +1 I presume the whole reason we need this is that *existing* parsers are blindly assuming that application/atom+xml means a feed document. If that is an invalid assumption, then I think (B) is the way to go. If not, them I'm unclear what the problem is. -- Ernie P.
Re: Atom Entry Documents
On 12/10/06, James M Snell [EMAIL PROTECTED] wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. The only question is whether or not to use a new media type or an optional type param. I'm going to write up an I-D this week. Please let me know which of the two approaches below y'all prefer... Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed +1. I believe other UA-visible Atom document syntax qualifiers will be needed/coming downstream. For example. ones describing the expected extension model(s) of the target Atom document. Feed vs. entry is just one syntax variant of an Atom document, others of UA interest might be this is an Atom document containing OpenSearch results or this is an Atom Document that describes media using Media RSS extensions. I'm not sure that treating each syntax variant as a unique MIME type is a scalable approach for the long haul. One specific issue is that you will also have to deal with combinations (ex this Atom document is a feed that contains OpenSearch results listing Media RSS entries). Cheers! -- Kyle
RE: Atom Entry Documents
At 10:32 06/12/11, Franklin Tse wrote: Option B) New Entry media type application/atom.entry+xml +1 +1 #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Atom Entry Documents
On 12/12/06 5:56 AM, Kyle Marvin [EMAIL PROTECTED] wrote: application/atom+xml; type=entry application/atom+xml; type=feed I believe other UA-visible Atom document syntax qualifiers will be needed/coming downstream. For example. ones describing the expected extension model(s) of the target Atom document. Feed vs. entry is just one syntax variant of an Atom document, others of UA interest might be this is an Atom document containing OpenSearch results or this is an Atom Document that describes media using Media RSS extensions. I'm not so sure. I see the difference between the two being one vs many, and nothing more. What you want could however be accommodated by additional parameters.. I'm not sure that treating each syntax variant as a unique MIME type is a scalable approach for the long haul. One specific issue is that you will also have to deal with combinations (ex this Atom document is a feed that contains OpenSearch results listing Media RSS entries). application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS (or syntax to that effect) e.
Re: Atom Entry Documents
On 12/10/06, James M Snell [EMAIL PROTECTED] wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. Erm, isn't it up to the chairs to declare concensus? AFAICT, the discussion I was involved in failed to achieve it. If I'm mistaken, I'll be happy to put in my 2c on a solution of course. Mark.
Re: Atom Entry Documents
Mark Baker wrote: On 12/10/06, James M Snell [EMAIL PROTECTED] wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. Erm, isn't it up to the chairs to declare concensus? The I-D would be an individual draft, not a WG draft. The chairs only decide consensus on WG stuff. Once I get the initial version of the draft up, we can see if it makes sense to move it forward as a WG draft, in which case, I'll gladly let the chairs handle it. :-) AFAICT, the discussion I was involved in failed to achieve it. If I'm mistaken, I'll be happy to put in my 2c on a solution of course. I think there was consensus that some form of mechanism for identifying entry documents would be helpful. Where I see a lack of consensus is on the specific mechanism to use. - James
Re: Atom Entry Documents
Sure you can. Adding this to mime.types... application/atom+xmlatom application/atom+xml;type=entry entry application/atom+xml;type=feed feed works just fine in apache2. Ask for a static file *.atom, and you get application/atom+xml. Ask for a static file *.entry and you get application/atom+xml;type=entry. - James Hugh Winkler wrote: application/atom.entry+xml Another reason for +1 for B: consider serving static files, some of type entry, some of type feed. You can give each file type a different extension (.atom, .atom-entry) and configure Apache to serve the correct mime type for each. You could not configure Apache to serve files with the right type parameter, if you choose A.
Re: Atom Entry Documents
On 12/11/06, Eric Scheid [EMAIL PROTECTED] wrote: On 12/12/06 5:56 AM, Kyle Marvin [EMAIL PROTECTED] wrote: application/atom+xml; type=entry application/atom+xml; type=feed I believe other UA-visible Atom document syntax qualifiers will be needed/coming downstream. For example. ones describing the expected extension model(s) of the target Atom document. Feed vs. entry is just one syntax variant of an Atom document, others of UA interest might be this is an Atom document containing OpenSearch results or this is an Atom Document that describes media using Media RSS extensions. I'm not so sure. I see the difference between the two being one vs many, and nothing more. What you want could however be accommodated by additional parameters.. Exactly. But the key point is that at some point you _need_ the additional parameters, so let's stop thinking we can cram everything into the base media type/subtype and be limited by UAs that understand them (only) and start using parameters! I'm not sure that treating each syntax variant as a unique MIME type is a scalable approach for the long haul. One specific issue is that you will also have to deal with combinations (ex this Atom document is a feed that contains OpenSearch results listing Media RSS entries). application/atom+xml; type=feed,option=OpenSearch,option=MediaRSS (or syntax to that effect) Yup. Pretty close to what I was thinking. Cheers! -- Kyle
Atom namespace really not ending with / or # ?
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? Thanks, Jan
Re: Atom Entry Documents
What would the relationship of that document be to RFC4287? Cheers, On 2006/12/11, at 7:32 PM, James M Snell wrote: The I-D would be an individual draft, not a WG draft. -- Mark Nottingham http://www.mnot.net/
