Re: draft-ietf-atompub-protocol-04.txt
As a further clarification of my ideas about replacing contents attribute with a content element specifying the specific allowed MIME Types. I chose an element because my understanding is that XML attributes are assumed to be listed singly (only one name/value pair per name) whereas an element can be listed multiple times with different values or attributes. I propose the following modification to Section 8.1. For your reference, the MIME Types are listed by the IANA at http://www.iana.org/assignments/media-types/index.html It still seems to me that this would provide a hugely powerful capability to ATOM. Specifically, note the Documents, Pictures, and Audio collections in the example. For Section 8.1 The Introspection Document has the media-type 'application/ atomserv+xml', see Section 11 ?xml version=1.0 encoding='utf-8'? service xmlns=http://purl.org/atom/app#; workspace title=Main Site collection contents=entries title=My Blog Entries href=http://example.org/reilly/feed; content type=application/atom+xml content type=application/soap+xml /collection collection title=Documents href=http://example.org/reilly/documents; content type=application/atom+xml content type=application/soap+xml content type=application/msword /collection collection title=Pictures href=http://example.org/reilly/pic; content type=image/jpeg content type=image/gif content type=image/png content type=image/tiff /collection collection title=Audio href=http://example.org/reilly/pic; content type=audio/mpeg content type=audio/wma /collection /workspace workspace title=Side Bar Blog collection title=Entries href=http://example.org/reilly/feed; content type=application/atom+xml content type=application/soap+xml /collection collection title=Books href=http://example.org/reilly/books; content type=application/atom+xml content type=application/soap+xml /collection /workspace /service This specifies that workspace/collection Main Title/My Blog Entries can be operated on by a generic atom publishing tool, and so can Documents. Collection Pictures however is designed to take only the image types listed. If your ATOM publishing tool can work with these types, then it may be able to work with the collection using APP. The APP does specify certain actions that alternatiely can or must be supported by each collection and the Pictures collection can certainly handle each of these actions, including POST and GET to retrieve collection information associated with this Collection. commentary Even if we were to simply define audio as a separate content attribute (content=audio), it still would not have anywhere near the specificity of defining the exact MIME Types allowed. And I predict we would run into all kinds of compatibility problems with clients and servers if MIME Types are not listed SOMEWHERE for the client to determine. A situation which is elegantly solved by this proposal, in my opinion. /commentary Greg Smith --- Greg Smith [EMAIL PROTECTED] wrote: Joe, Thanks for your comments on my comments ;-) While we could create a whole series of entry, generic, and other types, it might be better to consider listing for each collection, the acceptable Content-Types. This document is just the 'basic' protocol, where we are describing the basic mechanisms and collection types. We are expecting to produce a further specification that covers editing collections of other types of documents, such as templates, etc. In the current specification draft (04), it looks like the entry and generic both specify identical actions (in the table showing Body/No body versus GET/PUT/DELETE/POST. So the real difference between the two is in the Content-types that each can handle: generic is unspecified, while entry is only defined as application/atom+xml or application/soap+xml. In addition, the PROTOCOL specifies which ATOM elements are Roundtrip. The advantage of specifying Content-Types as opposed to contents attribute of entry and generic (and further definitions): 1) immediately gain the ability of the client to discern acceptable Content-Types, something sorely missing from the current specification. 2) immediately gain the advantage of the client being able to determine if it can talk to the ATOM URI. (Graphic applications can talk to ATOM APP that accept image/*, audio applications=audio/*, etc) 3) Do not have to amend a specification (or create a new one) in order to handle every single Content-Type. 4) Adding different Content-Types to the allowable formats immediately opens the specification to a wide range of fairly obvious uses in the podcasting,
Re: draft-ietf-atompub-protocol-04.txt
Greg, All excellent observations and comments. My replies are inline. On 5/10/05, Greg Smith [EMAIL PROTECTED] wrote: In reference to draft-ietf-atompub-protocol-04.txt Just a quick readthrough and I have a few comments: 4.2 Discovery: good description and easing into the meat of the document. 6. Should probably reference see section 8.1.1.3.1.1. Good points. I have started an errata page for this draft on the wiki: http://www.intertwingly.net/wiki/pie/ProtocolDraft04Errata 6.1 In the table, what does x mean? Not allowed? Seems like it means something else, but not explicitly stated. I'm concerned about the ability of a client, given a Service Document (whether Autodiscovered or not), to determine what the Service Document covers. I think this is where the entry and generic types are going, but it seems like it might be advantageous to tie the Service Document to Content-Types. Suppose I am a blog hosting service and I allow direct photo, video, audio, and text blogs. By direct I mean I allow someone to post a photo directly to a photo blog without any text or metadata in it whatsoever. I will probably want a public service document that lists the hrefreadonly links for viewers and a private service document for my posting clients. If I do this, and then provide a series of collections within the service document, there is no way to automatically sort out what kind of content to post to each of the collections. If I want you to be able to program dumb clients that provide little or no metadata (like directly from a camera or mp3 recorder or phone), then it would be nice to provide a photo collection to POST my photos to. While we could create a whole series of entry, generic, and other types, it might be better to consider listing for each collection, the acceptable Content-Types. Right now, it looks like a client has to trial and error the Content-Types to determine the allowed Content-Types. It would even be nice to provide a preferred Content-Type for each collection as well, but I'm not sure that would be necessary. This document is just the 'basic' protocol, where we are describing the basic mechanisms and collection types. We are expecting to produce a further specification that covers editing collections of other types of documents, such as templates, etc. Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: draft-ietf-atompub-protocol-04.txt
Joe, Thanks for your comments on my comments ;-) While we could create a whole series of entry, generic, and other types, it might be better to consider listing for each collection, the acceptable Content-Types. This document is just the 'basic' protocol, where we are describing the basic mechanisms and collection types. We are expecting to produce a further specification that covers editing collections of other types of documents, such as templates, etc. In the current specification draft (04), it looks like the entry and generic both specify identical actions (in the table showing Body/No body versus GET/PUT/DELETE/POST. So the real difference between the two is in the Content-types that each can handle: generic is unspecified, while entry is only defined as application/atom+xml or application/soap+xml. In addition, the PROTOCOL specifies which ATOM elements are Roundtrip. The advantage of specifying Content-Types as opposed to contents attribute of entry and generic (and further definitions): 1) immediately gain the ability of the client to discern acceptable Content-Types, something sorely missing from the current specification. 2) immediately gain the advantage of the client being able to determine if it can talk to the ATOM URI. (Graphic applications can talk to ATOM APP that accept image/*, audio applications=audio/*, etc) 3) Do not have to amend a specification (or create a new one) in order to handle every single Content-Type. 4) Adding different Content-Types to the allowable formats immediately opens the specification to a wide range of fairly obvious uses in the podcasting, videocasting, *casting. And even in corporate use, building in the parsing of Content-Types makes available any kind of syndicated content whatsoever using the same tools built around the APP specification. The current use of contents attribute still may have its place (in resolving duplicate Content-Type applications such as application/atom+xml templates vs. application/atom+xml entries -- but I'm not fully convinced of this example, however, there may be others). And then to cover the other specification listed under contents=entry: you could specify that all application/atom+xml entries provide Roundtrip atom:updated and atom:id elements. I don't *think* that this would adversly impact other uses of atom or APP. Again, just thoughts that I'm happy to debate. I don't want to step on anyone's toes here. Greg Smith Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
