Re: PaceEntryMediatype
* 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. [Note: subscribing to an entry document is actually somewhat useful in one sense and might become customary in the future, eg. to track changes to a document. However, that’s still an entirely different use case from subscribing to feed.] Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: PaceEntryMediatype
* James M Snell [EMAIL PROTECTED] [2006-11-29 17:40]: http://www.intertwingly.net/wiki/pie/PaceEntryMediatype +1 * Thomas Broyer [EMAIL PROTECTED] [2006-11-29 20:35]: I'd largely prefer augmenting the existing media type with a 'type' parameter: - application/atom+xml = either feed or entry (as defined in RFC4287) - application/atom+xml;type=feed = feed - application/atom+xml;type=entry = entry -0 How about defining a tree similar to the */vnd.* one? - application/atom+xml = feed or entry document - application/atom.categories+xml = category document - application/atom.service+xml = service document ...and of course, if this proposal is finally accepted: - application/atom.entry+xml = entry document +1 I like this very much; it would put some order in the proliferation of Atom-related MIME types. As for Tim's concerns, I'd also prefer having it done outside the APP. +0 Also, the APP draft would need to be updated to remove the entry special value for app:accept, as it would be equivalent to the new or revised media type (app:accept=application/atom+xml;type=entry or app:accept=applicationAtom.entry+xml) +1 Unification is good. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Autodiscovery IPR and Process Concerns
On 11/30/06, A. Pagaltzis [EMAIL PROTECTED] wrote: What rhetorical device is it to point out the rhetorical devices used by other participants in a discussion? Gosh, Aristotle. I'm sure I don't know. Y'all let me know when y'all figure it out. - Bobby
Re: PaceEntryMediatype
Jan Algermissen wrote: Hi James, On Nov 29, 2006, at 5:16 PM, James M Snell wrote: == Status == Proposed == Rationale == The fact that one media type is used for both Feed and Entry documents has repeatedly come up as a problem on more than one occasion. I took that to refer to the problem I saw (doing an additional check on the root element) but Mark's comment made me realize that this is to small of a problem to warrant the media type separation of something so tied together, IMO. Are there other problems you had in mind when writing the Pace? One example. UA POSTs content to a collection. The media type chosen by the client is application/atom+xml and is accepted by the collection. Now say the client posted a feed containing several entries. What should the server decide to do? It could reject the request altogether but on what ground? How to inform properly the UA? If we had a specific media type (or at least a ;type=entry) for Atom entries you would avoid such issue or be able to return a 415 error code. More generally feed and entry documents are semantically distinct enough that they should be distinguished in their media-type one way or the other. I have hard times understanding why it hasn't been done so in the first place. Better be safe than sorry. Well it seems we are sorry :) It's interesting however because now that APP has reached a point where it stable enough to be implemented we can see that issues are not the same for server and client implementors. Considering what happens still now with HTTP (see for instance the Content-Location discussion over at the HTTP-WG) I hope the APP WG and the specification editors are taking great care to limit the possibilities of future conflicts once APP gets heavily deployed and used. If things can safely be changed now then let's do it. - Sylvain
Re: PaceEntryMediatype
On Nov 29, 2006, at 7:22 PM, James M Snell wrote: One such problem occurs in atom:link and atom:content elements. Specifically: atom:link type=application/atom+xml href=a.xml / atom:content type=application/atom+xml src=b.xml / Given no other information I have no way of knowing whether these are references to Feed or Entry documents. And what is the problem with that? Jan - James Mark Baker wrote: -1 - there's nothing special about an entry document - AFAICT (because they're not referenced from the pace), the problems referred to have other causes. I prefer we fix those instead. Mark.
Re: [rss-public] Autodiscovery IPR and Process Concerns
James M Snell schrieb: ... Now, to the WG as a whole: I really don't have any agenda for the autodiscovery stuff other than to help foster it along. If y'all think there is a need for a I-D defining autodiscovery for Atom and APP, I've got a few spare cycles to help with the editing. If y'all think the HTML5 stuff is sufficient, that's fine with me too. If y'all want to go some other direction with it, whatever. ... My 2 cents: it's nice that the HTML5 guys are looking at this, but they are so far away from being able to deliver something that I really would prefer that this is documented now. So, yes, I think you're on the right track. Best regards, Julian
Re: PaceEntryMediatype
Thomas Broyer wrote:
James M Snell wrote:
Create a new media type for Atom Entry Documents:
application/atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
-0.5.
Using a type parameter seems like a more elegant solution -- and
achieves the same effect.
I'd largely prefer augmenting the existing media type with a 'type'
parameter:
- application/atom+xml = either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed = feed
- application/atom+xml;type=entry = entry
+1.
This looks IMHO like a cleaner solution; in particular
application/atom+xml fits in nicely as special (or rather more generic)
case of application/atom+xml;type=(feed|entry).
{{{
Atom Entry Documents are identified with the
application/atomentry+xml media type (See section 15).
}}}
How about defining a tree similar to the */vnd.* one?
- application/atom+xml = feed or entry document
- application/atom.categories+xml = category document
- application/atom.service+xml = service document
...and of course, if this proposal is finally accepted:
- application/atom.entry+xml = entry document
-1. I would not go down this road; the trees were designed for a
different purpose. For (optional) type/profile parameters, however,
there is precedent.
As for Tim's concerns, I'd also prefer having it done outside the APP.
+1. A separate Atom Media Types RFC would be good.
Andreas Sewe
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
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
On Nov 30, 2006, at 2:13 AM, Jan Algermissen wrote: On Nov 29, 2006, at 7:22 PM, James M Snell wrote: One such problem occurs in atom:link and atom:content elements. Specifically: atom:link type=application/atom+xml href=a.xml / atom:content type=application/atom+xml src=b.xml / Given no other information I have no way of knowing whether these are references to Feed or Entry documents. And what is the problem with that? Here's one problem: in this and the autodiscovery case, the UA can't tell without fetching the remote resource whether it's appropriate to display a subscribe link. In fact, even if the remote resource is a feed, it may not be appropriate to subscribe to, because it may be an archive document rather than the live end of a feed. Of the options presented, I'd favor adding a type parameter to application/atom+xml. In addition to feed and entry, we may want archive.
Re: PaceEntryMediatype
Thomas Broyer wrote:
snip
I'd largely prefer augmenting the existing media type with a 'type'
parameter:
- application/atom+xml = either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed = feed
- application/atom+xml;type
=entry = entry
/snip
+1
On 11/29/06, Thomas Broyer [EMAIL PROTECTED] wrote:
2006/11/29, James M Snell:
Create a new media type for Atom Entry Documents:
application/atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
I'd largely prefer augmenting the existing media type with a 'type'
parameter:
- application/atom+xml = either feed or entry (as defined in RFC4287)
- application/atom+xml;type=feed = feed
- application/atom+xml;type=entry = entry
{{{
Atom Entry Documents are identified with the
application/atomentry+xml media type (See section 15).
}}}
How about defining a tree similar to the */vnd.* one?
- application/atom+xml = feed or entry document
- application/atom.categories+xml = category document
- application/atom.service+xml = service document
...and of course, if this proposal is finally accepted:
- application/atom.entry+xml = entry document
As for Tim's concerns, I'd also prefer having it done outside the APP.
Also, the APP draft would need to be updated to remove the entry
special value for app:accept, as it would be equivalent to the new or
revised media type (app:accept=application/atom+xml;type=entry or
app:accept=applicationAtom.entry+xml)
--
Thomas Broyer
Re: PaceEntryMediatype
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. Well having two media types also helps at a lower level such as HTTP (content negotiation for one thing). - Sylvain 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
2006/11/30, Mark Baker: The real problem here AIUI - at least in the context of HTML 5's inferred rel=feed bit - is not just entry documents, it's any Atom document which wouldn't normally be considered a feed by a typical user; something that most people would be interested in subscribing to. An example I gave on the whatwg list was an MHTML-like (MIME multipart) package, but there are many other possible examples of course; not all RFC 4287 feed documents are feeds in this sense. Yes. If HTML 5 (and current practice) doesn't change, but we defer to them for the specification of autodiscovery, then a new media type would be one way forward. But it should be reusable for all non-feed (i.e. from a user POV, as above) Atom documents, not just entry documents; perhaps application/atom-no-feed+xml. It's an ugly hack, but it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. -1 This means RSS would need two media types. This also means an HTML document can be a feed, or it needs its own media type. In an entry page in a blog-like scenario, we could find: link rel=feed href=/feed.atom type=application/atom+xml;type=feed link rel=feed href=/ type=text/html which tells you the page believes it is an item in the linked feeds. Then , in /feed.atom: atom:link rel=alternate href=/ type=text/html / and in the /: link rel=alternate href=/feed.atom type=application/atom+xml;type=feed And yes, HTML pages are subscribable, either using a microformat (see the W3C's home page, from which the RSS is actually produced using an XSLT stylesheet), or using user-defined scrapping (some aggregators allow you to subscribe to any web page; they try to infer the entries from the semantical markup –h1, h2, h3, etc.– and you can customize the mechanism in per-feed basis: this page uses h2, this one uses h3 with class=article, etc.) The relation from the entry page to the feed or home page is the same (hey, they are alternates!): they are feeds, whatever their representation (Atom, RSS, HTML, etc.) The difference with container? a feed is known to have a representation which only exposes a subset of the contained items. This is the same as: link rel=contents href=/toc.html type=text/html link rel=contents href=/toc.opml type=what's the media type for OPML? Another way forward, because the rel=feed inference is triggered not just by the media type but by the alternate relationship keyword, is to create a non-feed alternate relationship (alternate-non-feed? ick). I prefer the new relationship to a new media type because it's less disruptive; it doesn't require futzing around with existing specs and implementations. I'd prefer basing autodiscovery on the media types and not at all on the relationships. A feed relationship would only help finding the living resource (similar to rel=current in the Atom Relationship Registry) if you're not already on it (in which case, rel=alternate would be used). UAs would then obviously continue to support autodiscovery using alternate all-over-the-place, this would just be a lucky side-effect; and everyone would be happy. -- Thomas Broyer
Re: [rss-public] Autodiscovery IPR and Process Concerns
Julian Reschke wrote: My 2 cents: it's nice that the HTML5 guys are looking at this, but they are so far away from being able to deliver something that I really would prefer that this is documented now. So, yes, I think you're on the right track. I just want to clear up this misconception about the status of the the HTML5 draft. As a whole, it's true that it's going to take about 15 years or so for the spec to reach the W3C recommendation status (assuming the work does move to the W3C, which is currently being worked out). However, it's important to realise what the recommendation status actually means. For a spec to become a REC, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you'll begin to understand why the time frame seems so long. However, the WHATWG recognises and understands the problem with this: different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. canvas). But other sections are still being actively worked on and changed regularly, or not even written yet. The details are still being worked out, but the plan is to indicate the maturity level on a per-section basis. Sections like the Link Types, which is relatively simple, isn't going to take long to become interoperably implemented. In fact, Mozilla is already implementing the new autodiscovery features for Firefox 3.0, and it shouldn't take long for places like Technorati, Bloglines, etc. to implement follow. Once a section is interoperably implemented, it's quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use (as autodiscovery already is today). The point to all this is that you shouldn't place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually. Thus, while proceeding with Autodiscovery as an RFC may yield a fully complete and endorsed specification more quickly than HTML5, the end result and the time it takes for implementations to catch up is going to be the same. In fact, I believe leaving it in the hands on the WHATWG will in fact lead to a much higher quality specification because of the extensive experience that the editor has with writing them. -- Lachlan Hunt http://lachy.id.au/
Re: PaceEntryMediatype
On 11/30/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: 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. Well having two media types also helps at a lower level such as HTTP (content negotiation for one thing). True, but if entry documents are more or less aliases for single-entry feeds, why would anybody need to negotiate for one or the other? I suggest that would have to be pretty obscure use case. 8-) Mark.
Re: PaceEntryMediatype
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
The key problem with application/atom+xml;type=entry is that at least one major browser (Firefox 2.0) still treats it as a feed and shows the subscribe link. So while the type parameter is a potentially more elegant solution, the new media type approach would likely be far less disruptive. - James Antone Roundy wrote: [snip] Of the options presented, I'd favor adding a type parameter to application/atom+xml. In addition to feed and entry, we may want archive.
Re: PaceEntryMediatype
Jan Algermissen wrote: [snip] Are there other problems you had in mind when writing the Pace? Well, there are the issues that came up with regards to the APP accept element; the issues regarding whether Atom Feeds can be posted to an APP collection; the issue in the collection of collections use case where it's not clear if content type=application/atom+xml src=foo / points to an entry or a feed; I'm sure there are others that I'm not thinking of right at the moment. It seems that every couple of months the issue of the media type duality comes up. - James
Re: PaceEntryMediatype
On 11/30/06, James M Snell [EMAIL PROTECTED] wrote: The key problem with application/atom+xml;type=entry is that at least one major browser (Firefox 2.0) still treats it as a feed and shows the subscribe link. Of course it does. Any program interested in consuming information is going to ignore unknown parameters. -- Robert Sayre
Re: PaceEntryMediatype
Mark Baker wrote: [snip] If HTML 5 (and current practice) doesn't change, but we defer to them for the specification of autodiscovery, then a new media type would be one way forward. But it should be reusable for all non-feed (i.e. from a user POV, as above) Atom documents, not just entry documents; perhaps application/atom-no-feed+xml. It's an ugly hack, but it's better than the alternative of many more specific Atom-related media types, which atomentry+xml might set a precedent for. Blech! :-) I think it's worthwhile to separate the two distinct issues at play: The Purpose of the Link and the Type of Resource. The ambiguity in the media type has come up several times in WG discussions for more than just autodiscovery. Every time it comes up there is some speculation about whether adding a type parameter would be helpful then folks move on to something else without really coming to a conclusion. I agree with you that the HTML5 definition of alternate is lacking but I understand why they've done things that way and I applaud their effort. They're documenting existing practice even if it is fundamentally flawed. At least they're moving things in the right direction with the feed link relation but it's too early to tell if that effort is going to pan out in the end. [snip] I prefer the new relationship to a new media type because it's less disruptive; it doesn't require futzing around with existing specs and implementations. Possibly. But at this point I'm not yet convinced. - James
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
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
Bill de hOra wrote: Well it's all octets so in one sense the processing is the same. [snip] Btw, My apologies if my original comment about the xml parsing came across as being snarky; that was not the intention. The point I was making was that how these things are processed depends entirely on how you intend to use 'em. So far I've seen no evidence that anyone intends to use Entry Documents in the same way they use Feed Documents. - James
Re: [rss-public] Autodiscovery IPR and Process Concerns
On 11/30/06, Lachlan Hunt [EMAIL PROTECTED] wrote: The point to all this is that you shouldn't place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually. Thus, while proceeding with Autodiscovery as an RFC may yield a fully complete and endorsed specification more quickly than HTML5 Actually, the process you describe is pretty much identical to the IETF process in letter. For example, it took many years for RFC3986 to appear, describing URIs at the level of Full Standard. In practice, the WHAT-WG is more accountable, because there is a documented process for resolving disputes that actually empowers the group's participants. You'll find no such thing in the IETF, especially with an individual draft. The WHAT-WG is also much more rigorous in testing and research than the IETF, so I have to agree that there is little benefit to pursuing the Internet-Draft. Claims that the WHAT-WG is too slow are overblown at best -- getting something to Proposed Standard is not that interesting. The (active!) wiki at http://feedautodiscovery.org is rapidly eclipsing any other source on autodiscovery, and it can include information that would not be permitted in an IETF or WHAT-WG document, so it will always be more valuable and current. -- Robert Sayre
Re: PaceEntryMediatype
Summary of thoughts and questions: *** Problems with the status quo *** A) Consumers don't have enough information (without retrieving the remote resource) to determine whether to treat a link to an Atom document as a link to a live feed, a feed archive, or an entry. (Is it appropriate to poll the link repeatedly? How should information about the link be presented to the user?) B) APP servers can't communicate whether they will accept feed documents or only entry documents. *** Possible solutions *** 1) Add a type parameter to the existing media type: + With the exception of a few details, the documents are all exactly the same format (does it contain a feed element, or does it start at the entry element, is it a live feed document or an archive, etc.), so a single media type makes the most sense (definitely for live feeds vs. archives, less certainly for feeds vs. entries). - Some existing applications will ignore the parameter and may handle links to non-live-feeds inappropriately - Some existing applications may not recognize application/atom +xml;type=feed as something appropriate to handle the same way they handle application/atom+xml now. ? I haven't been following development of the APP, so forgive my ignorance, but can parameters be included in the accept element? 2) Create (a) new media type(s) (whether like application/atomentry +xml or application/atom.entry+xml): + Applications that currently treat all cases of application/atom+xml the same would ignore non-feed links until they were updated to do something appropriate with the new media type. - Differentiating between live feeds and archives by media type seems really wrong since their formats are identical. This isn't as big a negative for entry documents, but it still seems suboptimal to me. - If a media type were created for archive documents, would APP accept including application/atom+xml imply acceptance of archive documents too? Neither yes nor no feels like a satisfying answer. 3) Use @rel values to differentiate: - That territory is already a bit of a mess, what with feed vs. alternate vs. alternate feed vs. feed alternate -- why make it worse? + That territory is already a bit of a mess, what with feed vs. alternate vs. alternate feed vs. feed alternate -- why not work on all these messy problems in the same place? - That wouldn't help with the APP accept issue. 4) Create a new media type for entry documents, and add a parameter to application/atom+xml to differentiate between live and archive feeds (and for any other documents that have the identical format, but should be handled differently in significant cases). - Doesn't prevent existing apps that ignore the parameter from polling archive documents. + Does solve the rest of the problems without the negatives of #2 above. 5) Create a new media type for entry documents, and use @rel values to solve issues that doesn't solve: +/- Messy territory If we were starting from scratch, I'd probably vote for #1. Since we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think about #5 more first. Antone
Re: PaceEntryMediatype
Excellent summarization Antone, thank you. Antone Roundy wrote: [snip] ? I haven't been following development of the APP, so forgive my ignorance, but can parameters be included in the accept element? I'd have to double check the definition of media-range but the original intent was that parameters would be allowed but likely rarely used. [snip] 4) Create a new media type for entry documents, and add a parameter to application/atom+xml to differentiate between live and archive feeds (and for any other documents that have the identical format, but should be handled differently in significant cases). [snip] If we were starting from scratch, I'd probably vote for #1. Since we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think about #5 more first. I personally don't care so much about differentiating archive feeds. At this point I'm thinking that some combination of 4 and 5 would be best. - James
Re: PaceEntryMediatype - Options
Hi Antoine, On Nov 30, 2006, at 10:21 AM, Antone Roundy wrote: Summary of thoughts and questions: Thanks -- this is incredibly helpful. However, might I suggest a couple more options? 6) Change expectations, not the spec. Consumers must poll the feed to inspect the metadata, and Servers must accept both. 7) Disallow entry-only documents Require all Atom documents to have a feed wrapper in order to be parsed properly. This is basically #4 + procrastination. :-) I'm not saying these are necessarily _good_ options, but I'd like to be sure that whatever we do propose is superior to either of these; i.e., is the use of entry-only documents important enough to justify all this work? Thanks, -enp *** Problems with the status quo *** A) Consumers don't have enough information (without retrieving the remote resource) to determine whether to treat a link to an Atom document as a link to a live feed, a feed archive, or an entry. (Is it appropriate to poll the link repeatedly? How should information about the link be presented to the user?) B) APP servers can't communicate whether they will accept feed documents or only entry documents. *** Possible solutions *** 1) Add a type parameter to the existing media type: + With the exception of a few details, the documents are all exactly the same format (does it contain a feed element, or does it start at the entry element, is it a live feed document or an archive, etc.), so a single media type makes the most sense (definitely for live feeds vs. archives, less certainly for feeds vs. entries). - Some existing applications will ignore the parameter and may handle links to non-live-feeds inappropriately - Some existing applications may not recognize application/atom +xml;type=feed as something appropriate to handle the same way they handle application/atom+xml now. ? I haven't been following development of the APP, so forgive my ignorance, but can parameters be included in the accept element? 2) Create (a) new media type(s) (whether like application/atomentry +xml or application/atom.entry+xml): + Applications that currently treat all cases of application/atom +xml the same would ignore non-feed links until they were updated to do something appropriate with the new media type. - Differentiating between live feeds and archives by media type seems really wrong since their formats are identical. This isn't as big a negative for entry documents, but it still seems suboptimal to me. - If a media type were created for archive documents, would APP accept including application/atom+xml imply acceptance of archive documents too? Neither yes nor no feels like a satisfying answer. 3) Use @rel values to differentiate: - That territory is already a bit of a mess, what with feed vs. alternate vs. alternate feed vs. feed alternate -- why make it worse? + That territory is already a bit of a mess, what with feed vs. alternate vs. alternate feed vs. feed alternate -- why not work on all these messy problems in the same place? - That wouldn't help with the APP accept issue. 4) Create a new media type for entry documents, and add a parameter to application/atom+xml to differentiate between live and archive feeds (and for any other documents that have the identical format, but should be handled differently in significant cases). - Doesn't prevent existing apps that ignore the parameter from polling archive documents. + Does solve the rest of the problems without the negatives of #2 above. 5) Create a new media type for entry documents, and use @rel values to solve issues that doesn't solve: +/- Messy territory If we were starting from scratch, I'd probably vote for #1. Since we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think about #5 more first. Antone
Re: PaceEntryMediatype
On 1/12/06 5:21 AM, Antone Roundy [EMAIL PROTECTED] wrote: 5) Create a new media type for entry documents, and use @rel values to solve issues that doesn't solve: +/- Messy territory If we were starting from scratch, I'd probably vote for #1. Since we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think about #5 more first. Starting from scratch, idealised, I'd want different media types (or params) for entry documents and feed documents, and link type which clearly indicates this is for subscription, as distinct from this is an alternate representation, this is an archive, etc. Using the two mechanisms together allows combinations such as here is a feed you can subscribe to of the comments for this entry and here is a feed document listing related resources, but since it won't likely be updated don't bother subscribing. I'd like to be able to use a lot of the link types we currently use for html (directory, help, toc, related, next, etc) to refer to resources which happen to be serialised in the atom feed document format, and feel safe in knowing they won't be automagically treated as being subscription feeds. e.
Robert Sayre again banned from posting to the lists for 30 days
Because of his recent ad hominem attacks, I have temporarily suspended Robert Sayre's posting privileges for the two Atompub WG mailing list for 30 days, as specified in RFC 3934. If you have questions or comments about this action, please first take them to Tim and me offline.
Re: [rss-public] Autodiscovery IPR and Process Concerns
The AD was kind enough to point out that this statement is likely a bit too vague. The intended meaning was that I have no involvement in, or awareness of, IPR that is in any way relevant to the atom work. And, as far as I am aware, there's nothing I am required to disclose. - James James M Snell wrote: [snip] There's absolutely nothing to disclose. [snip]
