I have just read the latest 08 draft of the APP, and a few minor issues
came up that need to be clarified or handled consistently:
* Are HTTP redirects (3xx status codes) allowed when Retrieving an
Introspection Document (5.1), Retrieving a Resource (5.3.1), or Listing
Collection Members (5.4)? The draft is silent on this; possible status
codes aren't specified for GET requests. All that is said is that "The
server responds with a [introspection] document", "with the
representation of the resource", and "with an Atom Feed Document
containing the IRIs of the collection members," respectively.
But an APP server might, for example, want to map collection IRIs like
<http://example.org/themen/beispiel> to
<http://example.org/topics/example> via an HTTP redirect, making it
easier for people to memorize IRIs by exposing them in their own
language (in the above example, German). And there are probably other
use cases for this as well.
* When "Creating resources with POST" (8.1) "collections MAY impose
constraints on the media-types that are created in a collection and MAY
generate a response with a status code of 415 ("Unsupported Media
Type")." A clarification might be needed, however, since constraining
media types is not sufficient in order to prevent POSTing Atom feeds to
entry collections; both Atom feeds and entries have a media type of
"application/atom+xml".
What about rewording the above to "collections MAY impose constraints on
the formats that are created in a collection and MAY generate a response
with a status code of 415"? This uses the generic term "format",
following RFC 2616's explanation of status code 415. Furthermore it
omits the "Unsupported Media Type", since it can be misleading.
* Also, the wording of "Creating resources with POST" (8.1) and "Media
Collections" (8.3) may need some further refinement, since 8.1 states
that "collections MAY impose constraints [...]" whereas 8.3 states that
"Media Collections are collections whose member representations are not
constrained."
What about changing 8.3 as follows: "Media Collections are collections
whose member representations are not constrained to Atom Entries. It MAY
impose, however, further constraints on the formats created therein (see
8.1)."?
* Is the inconsistency between "application/atomserv+xml" and the
file extension of ".atomsrv" intentional? If not, could you please bring
those to in line since it's easy to forget about an 'e' or insert one
when it is not needed. (Personally I prefer "atomsrv" over "atomserv"
since the former is slightly shorter, but in the end I don't
mind, as long as it is handled consistently.)
* What about turning the <app:member-type> element into an attribute,
@type, on <app:collection>? At least in my understanding
<app:member-type> serves a purpose similar to the @type of Atom Text and
Content Constructs.
Furthermore, this would allow you to get rid of the last multi-word,
hyphen-separated name in APP. :-)
Well, that's it for now; I am back to lurking -- unless a Pace needs to
be written for any of these proposals. I would be happy to do that.
Regards,
Andreas Sewe
