Excellent. Here are some initial thoughts, I'll have more later. Some
are editorial in nature, others not.
5.3 Should we explictly specify that prior to updating an entry using
put, the client must perform a GET to retrieve the current
representation of the resource?
Question: This is likely implementation guide material but should
anything be said about the potential for concurrency problems? e.g.
Person A gets the resource, Person B gets the resource, Person B submits
changes, Person A submits the changes.. since there is no resource
locking, there is the potential for conflicts. Perhaps a single line of
text warning folks that resource locking is out of scope??
Section 2, 3 & 6: Move to sections 1.1, 1.2 and 1.3
Section 7: Instead of "discover capabilities and locations" make it
"discover the locations of available collections along with associated
metadata". Collections do not have capabilities.. at least none that we
are defining.
Section 7.2: Can we use application/atompub+xml for the media type instead?
Section 8.3: Can a media collection contain a member whose type is
application/atom+xml?
Section 11: Seeing the Title header in use makes me very afraid that
folks are going to start wanting the load up the HTTP headers with all
sorts of other types of metadata. e.g. description of the photo, whether
it is private or not, what tags to use to describe it, etc. I'm not
sure how else we can do this but do we really want to encourage a bunch
of implementation specific metadata being passed around in the HTTP headers?
Also, when I GET a member of a media collection using it's edit URI, do
the response headers have to contain the Title?
And it just seems wrong that the way I set the title initially, and the
way I change the title later are two completely different mechanisms
(e.g. the former uses an HTTP header, the latter uses an atom:entry)
Joe Gregorio wrote:
Draft -06 is now available:
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.html
Currently the IETF is under a moratorium on publishing
I-D's around the 64th IETF meeting. Once this moratorium
is lifted the above -06 version will be submitted for
publication. Until then let's move forward using the
version available above.
Text and XML versions are also available:
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.xml
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.txt
A lot of effort by Bill, the co-chairs and myself has gone into
making this draft much leaner and cleaner than -05.
A partial list of changes:
Massive repair of grammar, spelling and punctuation.
Added in PaceCollectionControl.
Removed {daterange}.
Added full RNC schema.
Collapsed Introspection and Collection documents into a single document.
Renamed 'search' to 'list'.
Simplified definition media and entry collections
and moved the discussion to the introspection element app:member-type.
Thanks,
-joe
--
Joe Gregorio http://bitworking.org
