James M Snell wrote:
1. Drops introspection documents. Get on Collection URI returns an
Atom feed containing a server-defined subset of entries.
Introspection doc can be defined in a separate I-D.
+0
2. The Atom feed returned by the collection MAY contain an
app:member-type element.
+0. Maybe not even needed in the core.
Without introspection document, you'll have to configure your AtomPP
client “one collection at a time”, so you'll know which collection is
“entry” and which one is “other”.
3. The Atom feed returned by the collection MAY contain an
app:list-template element to allow for client-defined subsets
-1. Not in the core. Wait for an introspection doc and make it an
extension within it.
4. All Collections are media collections by default. Servers MAY
choose to limit the membership to specific types. This eliminates the
need to explicitly distinguish media collections, greatly simplifying
the overall model. Entry collections are Media collections whose
content is limited to Atom Entry Documents.
No need to legislate in the core (see [1]). Just say that server MAY
choose to limit the membership to specific types and give examples
(PNG/JPEG images, Atom Entry Documents, etc.)
It might also be needed to add spec text saying that servers can
transform the submitted data from one type to another (e.g. from
OpenDocument to Atom Entry Document, or from BMP to PNG)
5. Clients may post anything to the server. The server accepts and
rejecrs whatever it wishes. The protocol is no more concerned about
whether valid atom:entry representations are posted as it is about
whether valid PNG files are posted. The server is responsible for
taking whatever is posted (and accepted) and creating an appropriate
member resource based on the input. For the core protocol, it does
not matter who generates atom:id or whether atom:author is present,
etc. Interestingly, this also gives us a degree of
backwards-compatibility with current AtomAPI (gregorio-09)
implementations and would allow servers to do things like creating
member entries in response to trackback pings and HTML form submissions.
If you propose NOT legislating that clients MUST send valid Atom
Entries, then +1.
If you propose explicitly saying the clients MAY send invalid Atom
Entries and servers MAY accept them, -1.
6. The metadata for a media resource can be updated by doing a POST
against the member resource IRI. This allows for setting/changing
things like the title and summary of a PNG, for instance. use of the
the Title HTTP header is dropped.
-1. Not in the core (it's however a good candidate for an extension)
====================================================================
1. Introduction
I've not read in detail below this line ;)
[1] http://www.imc.org/atom-protocol/mail-archive/msg02466.html
--
Thomas Broyer
