Subject: Re: draft-ietf-atompub-protocol-04.txt

From: Greg Smith <[email-masked]>
Date: Fri, 13 May 2005 09:11:20 -0700 (PDT)

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-masked]> 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,
> 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
> 
> 

__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail