Elias Torres wrote:
>
> Hi AtomPub folks,
>
> I am working with James Snell on the Abdera project and have almost
> completed an Atom PP implementation that will soon be available for
> interop testing. After reading the latest draft, a few
> questions/comments came up and wanted to make you aware of them. I
> will appreciate any discussion on it.
>
> 5.1 Do we need to specify the Accept header value for an instropection
> document? i.e. application/atomserv+xml
>
Not sure what you mean here. A content type for introspection docs is
defined in section 7.
> 5.3.1 Maybe the same question as before? Are you going to make any
> mention of content-type negotiation on GET to Member URI?
>
> 7.1 Should we have language-aware titles in app:collection? 7.2.2.1
> says that @title is language sensitive. I guess you may use xml:lang,
> but what about multiple language versions of the title.
>
If a service offers multiple language versions of a collection, it could
do so using multiple workspace elements.
<service>
<workspace xml:lang="en" title="...">
<collection title="..." href="http://example.org/foo"; />
</workspace>
<workspace xml:lang="fr" title="...">
<collection title="..." href="http://example.org/foo"; />
</workspace>
</service>
> 7.2.1 Has anybody expressed a need of having app:link elements in
> service, maybe to point to self or an alternate humand-readable
> representation of the service?
>
This was discussed a while back but was dismissed as YAGNI, especially
given that someone could extend the introspection doc using atom:link
elements to accomplish the same goal if it can be demonstrated to be useful.
> 8.3 I guess it makes sense for link/@rel=edit to be optional, but what
> about link/@rel=self? I didn't find the word 'self' in the
> specification. Google seems to require 'self' relationship in their
> posts and I like to have both a separation between GET/PUT for member
> URIs.
Back when it was assumed that the Member's Location URI was also it's
Edit URI, having the self didn't make a lot of sense. However, with
Gdata, the notion that the Location URI may not be the Edit URI makes
having a self link in the entry very useful.
>
> 8.4.2 Example of posting a PNG includes a Content-Location in the
> response header. In 8.1 you said that when the POST request contains
> an Atom Entry Document, the response from the server SHOULD include
> it, but nothing about when the request is not an Atom document. Are
> you suggesting we do the same for media post requests?
>
It should be the same for both. I do believe it should say when the
POST **response** contains an Atom entry document, the response SHOULD
include a Content-Location.
> 9. I'm not sure why we are forcing order by atom:updated. This gives
> no room to server-side or client requested ordering.
There's nothing stopping a server from providing alternative orderings
so long as a by-updated ordering is provided as the default.
>
>> From reading the spec, I do not think there is a requirement on
> collection page size. I think that it is a good idea, maybe it would
> be better to explicitly state so.
>
> Collections are a bit underspecified. I would like to know if you are
> planning to specify collection management protocol. For example, right
> now on my implementation, collections are created on-demand and its
> accept type is based on the first entry it was posted to it. However,
> I would like to be able to modify the title and add/remove additional
> accept types. This would make room for extension developers to add
> more metadata to the collection such as ACLs, owners, summaries, etc.
>
I do believe collection management was ruled out of scope.
> Regards,
>
> Elias Torres
> http://torrez.us/
>
>
