Re: Additional 'namespace' attribute on content element?
On 1/4/07, Jan Algermissen [EMAIL PROTECTED] wrote: I recall Mark Baker using something similar in his former RDF Forms draft: rf:Container xmlns:rf=http://www.markbaker.ca/2003/rdfforms/; xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; rdf:about=http://shoes.example.com/order-processor/; rf:acceptedMediaTypeapplication/xml/rf:acceptedMediaType rf:acceptedNamespace rdf:resource=http://shoe-standards.example.org/orders/shoes// rf:intent rdf:resource=http://shoe-standards.example.org/order-shoes// /rf:Container That just describes an expectation ala app:accept, rather than any inline content ala the type attribute on atom:content. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Re: Atom Entry docs
On 12/14/06, Henri Sivonen [EMAIL PROTECTED] wrote: On Dec 13, 2006, at 17:51, Mark Baker wrote: But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? The downside is that implementations that (quite reasonably) assume that application/atom+xml == feed are also reasonable when they ignore unknown media type parameters. True, but I think it's quite reasonable to interpret that behaviour as a bug. Given the options of a new type or a new parameter, I am +1 on the new type. (Although in general, I don't like the proliferation of application/*+xml types, because apps need to do root sniffing for application/xml anyway.) Let's not go there 8-) See; http://www.w3.org/2001/tag/doc/mime-respect.html#embedded Mark.
Re: Atom Entry docs
On 12/13/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Consider GData apps. Their docs aren't clear (tsk, tsk!) about the use of a media type when inserting entries[1], but if they're doing it properly then their services should be keying off of application/atom+xml, and so will break if that's changed. And? Should a status quo be better on the long term? I was just disagreeing with Tim's assertion that nothing will break. Other server implementations should have the same issue, of course. So please explain me what a server currently does upon receiving an Atom feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? Returning a 415 error code seems like the wrong option since the media-type is perfectly valid. So what should servers do? Should they pick-up randomly one of the entries part of the feed? How should UA deal with the returned message? AIUI, that's undefined, and will remain so no matter what is decided here. I don't understand what that has to do with a new media type breaking existing servers though. Of course, APP isn't finished yet, and so technically we shouldn't be worrying about breaking implementations that jumped the gun. But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? Mark.
Re: Atom Entry docs
On 12/13/06, Bob Wyman [EMAIL PROTECTED] wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. That's what I thought the type parameter option was, so sure, +1 on that too 8-) Mark.
Re: Atom Entry Documents
On 12/12/06, James M Snell [EMAIL PROTECTED] wrote: *If* the document proceeds to Proposed Standard, the new RFC would update RFC4287 either by adding a new type param or by deprecating the use of application/atom+xml for atom entry documents in favor of a new media type. No other part of RFC4287 would be affected. Ideally, I would much rather this be a WG draft. I pinged Tim about it the other day and he suggested that I go ahead with a I-D for now and that we can explore whether or not to move forward with it as a WG draft later. I'm uncomfortable with this. If there's consensus to do something about identifying entry documents, let's do that. If there isn't, let's not. Mark.
Re: Atom Entry docs
Tim, On 12/12/06, Tim Bray [EMAIL PROTECTED] wrote: I seems obvious to me that Atom Feed and Entry docs are potentially quite different things which can be used for entirely different purposes. The contention that an Entry doc is somehow really the same as a one-entry Feed doc is entirely unconvincing. The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG finding on Authoritative Metadata (http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear that it's advantageous to use HTTP headers to distinguish between different kinds of representations. Ok, well, I've already voiced my disagreement that entirely different purposes necessitates a new media type using HTML as an example. I also disagree that the TAG finding has any relevance here, except insofar as it says that a media type authoritatively determines meaning by virtue of pointing at a spec ... but every option on the table, including doing nothing, does that. But so be it, I'm happy to move on ... So I guess I'm in favor of us writing something down to address this problem. RFC4287 is now pretty widely implemented, so there is a distinct cost to screwing around with the well-known application/atom+xml. On the other hand, my perception is that virtually all software that knows about 4287 knows about feeds, rather than entries. Thus, it seems to me that introducing a parameter so that existing software might see application/atom+xml;type=feed *might* break some software. Maybe, but I'd be surprised. Though not, AFAIK, prescribed behaviour, convention is that unknown extension parameters are ignored. Implementors? But introducing a new media-type application/atom-entry+xml which only goes with standalone feed documents is very unlikely to break anything. I think it would break servers. Consider GData apps. Their docs aren't clear (tsk, tsk!) about the use of a media type when inserting entries[1], but if they're doing it properly then their services should be keying off of application/atom+xml, and so will break if that's changed. Other server implementations should have the same issue, of course. So I'm for James' option B) application/atom-entry+xml I'm -1 on that, but +1 on the type parameter. Cheers, [1] http://code.google.com/apis/gdata/protocol.html#Inserting-a-new-entry Mark.
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: PaceEntryMediatype
On 12/8/06, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: But that is an issue of linking semantics, not link target media types. Wrong. The link relation 'alternate' is perfectly valid for both Entry and Feed documents, depending on what type of resource they are linked from. An index page of a website can have an 'alternate' relation to an Atom Feed, while an individual article page (or entry page) can have an 'alternate' relation to an Atom Entry. As it can to a feed with one entry. Both link relations are identical, but the client has absolutely no clue before it GETs the URI whether what sits on the other end is an Atom Feed or an Atom Entry. Nor should it need to distinguish, just like it doesn't need to distinguish between a feed with multiple entries, versus one with one entry. Mark.
Re: PaceEntryMediatype
On 12/6/06, James M Snell [EMAIL PROTECTED] wrote: Mark Baker wrote: [snip] Isn't that just a case of people not implementing the whole spec though? FWIW, if that practice is widespread, then I think the group should consider deprecating entry documents. Minting a new media type won't help. The interesting question is *why* haven't those applications implemented support for Entry Documents. My guess is that Entry documents aren't particularly interesting to their use cases which is likely because they serve a different purpose. Makes sense. I forgot that entry documents were used for creation in APP. But serving different purposes does not necessitate a different media type. Both Firefox and Googlebot are voracious consumers of text/html documents, yet for very different purposes. Mark.
Re: PaceEntryMediatype
On 12/5/06, Jan Algermissen [EMAIL PROTECTED] wrote: Question: what does it mean (what do we have to look for) to use them as aliases?? It wasn't the most illustrative choice of words, but what I'm looking for is evidence that an entry is interpreted differently if it's found in an entry document, than if it were found in a feed document. If we turn up multiple interoperable examples of that, then a new media type is warranted because it's really two formats masquerading as one. Mark.
Re: PaceEntryMediatype
On 12/5/06, James M Snell [EMAIL PROTECTED] wrote: When I process this entry, http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0 What is the implied feed? Where do I get the implied feeds metadata? Title? ID? Anything? If the entry contained an atom:source element you might be able to assume that a logical feed is implied but absent any other evidence, this is a standalone entry document that can be processed without any assumption that a feed exists. Ok, but I don't see that this would necessitate a new media type. It's just an entry without a feed. You'd use the same code path to process that entry whether it were found in an entry or feed document, right? Sorry if I wasn't clear what I was looking for earlier by my use of the word alias. Mark.
Re: PaceEntryMediatype
On 12/5/06, James M Snell [EMAIL PROTECTED] wrote: Mark Baker wrote: [snip] Ok, but I don't see that this would necessitate a new media type. It's just an entry without a feed. You'd use the same code path to process that entry whether it were found in an entry or feed document, right? Not necessarily. Sure, it might be the same parser code, but not necessarily the same bit of code using the parser. Look at the way Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry documents versus Feed documents. The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. Isn't that just a case of people not implementing the whole spec though? FWIW, if that practice is widespread, then I think the group should consider deprecating entry documents. Minting a new media type won't help. Or, are there applications which only process entry documents and not feed documents? Mark.
Re: PaceEntryMediatype
I'd be happy to believe you James, if I could find where in the spec that was stated. If it looks like an alias, and acts like an alias ... 8-) Mark. On 12/4/06, James M Snell [EMAIL PROTECTED] wrote: And therein lies the problem: entry documents are NOT aliases for single-entry feeds. - James Mark Baker wrote: [snip] 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
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.
Re: PaceEntryMediatype
On 12/2/06, Daniel E. Renfer [EMAIL PROTECTED] wrote: The difference between a collection of entries and a single entry is an important one. Sure, once you get inside the Entry, everything is the same, but knowing ahead of time that you are requesting a single Entry assists in processing. But then you're talking about a different resource than the feed, and so should use a different URI than the feed URI. Mark.
Re: PaceEntryMediatype
Urgh, sorry for my tardiness; I'm falling behind on my reading. On 11/30/06, Thomas Broyer [EMAIL PROTECTED] wrote: I'd prefer basing autodiscovery on the media types and not at all on the relationships. All a media type tells you (non-authoritatively too) is the spec you need to interpret the document at the other end of the link. That has very little to do with the reasons that you might want to follow the link, subscribe to it, etc.. Which is why you need a mechanism independent from the media type. Like link types. Consider hAtom. If you went by media types alone, you'd be confronted with; link type=text/html href=hatom.html / Not particularly useful for subscription (or anything else for that matter) is it? This would be better; link rel=feed type=text/html href=hatom.html / Autodiscovery should ideally be based primarily on link types, and only secondarily - as an optimization - on media types. Even this should work; link rel=feed href=hatom.html / Mark.
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
-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: PaceEntryMediatype
On 11/29/06, Jan Algermissen [EMAIL PROTECTED] wrote: Hi Mark, would you suggest to put service and categories into application/atom+xml as well? I haven't paid much attention to those, but AFAICT they have different processing models (e.g. extensibility rules) and so IMO, comprise different document formats. Separate media types are fine. Hmm, ah, I think I see what you mean: When a peer declares it understands application/atom+xml the understanding of entry/ is mandatory anyhow. Despite the additional inspection into the documents root element feed and entry belong into the same family you cannot have one without the other therefore the media type should not be split. Is that what you think? 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. And +1 to what Henry just said in response to James. It's also not a huge deal to me. But I've just raised the rel=feed inference issue with the WHAT WG, so we'll see how that goes; if resolved to my liking, then there's one less reason for a new media type. Mark.
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote: There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed What ambiguity? There's no ambiguity AFAICT. But the WHAT spec does need fixing. Assuming rel=feed because of the value of a (non-authoritative!) media type conflates two independent concepts, and as a result may confuse users who are looking for syndication feeds but instead find themselves confronted with non-traditional (non-feed) Atom documents. If that's fixed, then this should work fine for entries (assuming alternate semantics); link rel=alternate type=application/atom+xml href=foo.atom / There's no need for a new media type. Mark.
Re: How to do RESTful SEARCH (was Re: Adding POST capability to atom:link)
On 11/2/06, Lisa Dusseault [EMAIL PROTECTED] wrote: This is an interesting assertion about REST. I don't yet agree with it as stated though I might after further discussion and elaboration. To provide a possible counter-example, I always found the HTTP SEARCH proposal http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html to be RESTful because - The results of a search are returned as a set of resource identifiers I'm not sure exactly what you mean by that Lisa, but AFAICT, the results of a SEARCH request does not have an identifier. A RESTful solution would be publish a form that could be used by a client to construct a URI that would return the search results (with GET, of course). Cheers, Mark.
Re: HTTP Accept Headers for Atom V1.0?
On Sat, Jul 16, 2005 at 06:48:58AM +0200, A. Pagaltzis wrote: * Bob Wyman [EMAIL PROTECTED] [2005-07-15 21:45]: What would the HTTP Accept Headers for Atom V1.0 look like? i.e. if I want to tell the server that I want Atom V1.0 but do not want Atom 0.3? There is no official MIME type for Atom 0.3, is there? Well, official in the sense that a spec was written and code was written to that spec; it's application/atom+xml; However, the canonical serialization of an Atom document is XML 1.0, and this is the only serialization that can be identified with the application/atom+xml media type. -- http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html So to answer's Bob's question, You can't do that. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Re: Old application/atom+xml issues
On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote: The most we can do is to say that such things are invalid, and to work with the producers to correct this. Sounds good to me. The majority of the existing atom 0.3 feeds are produced by a relatively few producers. I am confident that these producers will convert over quickly. I am also committed to getting the word out quickly that atom 0.3 feeds are not to be considered valid. In particular, I plan to update the feedvalidator to note this as a problem (first as a warning, and later I will change this to an error). Nice. Thanks for your vigilance, Sam. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Old application/atom+xml issues
I wanted to point out that comments I've made on the application/atom+xml media type registration template have not yet been incorporated into the syntax draft, nor have I received any feedback about why they needn't be. These are not show-stoppers by any means, but are also not exactly insignificant IMO. The comments are; http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/000713.html http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/000678.html (the former was sent to the IESG, but again, I received no feedback) Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Re: Old application/atom+xml issues
On Tue, Jul 05, 2005 at 10:33:00AM -0400, Robert Sayre wrote: On 7/5/05, Mark Baker [EMAIL PROTECTED] wrote: I wanted to point out that comments I've made on the application/atom+xml media type registration template have not yet been incorporated into the syntax draft, nor have I received any feedback about why they needn't be. See comments from Tim here: http://www.imc.org/atom-syntax/mail-archive/msg14423.html Sorry you didn't get direct feedback. :/ Ah, I should have thought to check the archives, thanks. It should have gone to ietf-types though, since that's where public review of media type registrations happen and where my comments were sent. I've CCd ietf-types on this message. Tim writes; He's got a point on the namespace being mentioned, which creates some semi-circular dependencies, sigh. As to whether it's currently in use, largely due to lobbying from us, recent releases of both Apache and IIS tie the application/atom+xml media type to the .atom extension, so if people are creating 0.3 files and calling them whatever.atom, this could be right. Having said that, I think we should push back. Because any such current usage is unlicensed by any spec, because we plan to aggressively deprecate Atom 0.3 once we get 1.0 out and since I suspect that 90% of 0.3 feeds come from one place we should have some success. IMO, it matters not that no spec prescribes the use of this media type for Atom 0.3 feeds. What matters is whether it's in use today, which we seem to agree is the case. This seems an important piece of information that implementors should know, which is my motivation for asking that it be called out in the interoperability considerations section of the template. Something like; Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification, make use of this media type despite Atom 0.3 not being compatible with Atom 1.0. As for the magic number, to keep it simple I'd suggest that none be defined by removing the magic number section. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
Martin, The general idea seems to be that conversion to HTML is good for human consumption with a browser, and for human navigation in an archive. message/rfc822 is the original, and may be very good for reuse in a mailer (e.g. for replying), except that mailers don't support it much at the moment. atom:content type=message/rfc822 src=http://www.example.org/lists/list/archive/12345/ Unfortunately, that's bad Atom. Section 4.1.3.1 of the format spec says; On the atom:content element, the value of the type attribute MAY be one of text, html, or xhtml. Failing that, it MUST be a MIME media type, but MUST NOT be a composite type (see Section 4.2.6 of [MIMEREG]). If the type attribute is not provided, Atom Processors MUST behave as though it were present with a value of text. where composite type is defined to be multipart/* and message/*. If the intent of that restriction was to avoid the whole non-XML attachments issue, then it seems to have failed to account for the use of the src attribute to include the data by reference rather than by value. I'm sorry that I didn't notice this earlier. 8-( Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
