Thanks James. James M Snell wrote: > > > 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.
I just meant if my server was supposed to ignore the request's Accept header and always return application/atomserv+xml. Like if I navigate to the url with my browser. I guess it's not a big deal because the browser sends "text/html, ..., */*". > >> 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> This looks very underspecified. If what you suggest is correct, then there's no way to figure out which workspace owns the collection since they don't have workspace:ids. Which begs the question as to what's the purpose of workspaces? What am I supposed to do with a workspace element? From what you say, I'd have to do an xpath on //collection/@href and get the unique list of them to find all collections at an endpoint but the workspace they come would be meaningless. Also it conflicts with: "In an app:workspace element, the first app:collection element MUST refer to the preferred or primary collection" So does it mean that if have a second collection with a Spanish title, then it'll show up as the first element in the "workspace" element declaring its preferred status, but that's just bogus. <workspace xml:lang="es" title="..."> <collection title="..." href="http://example.org/fu"; /> </workspace> I think that the semantics specified by that language are very hard to both interpret and enforce when it comes to the instrospection document and I'm not caught up with all the scenarios you might have discussed that could make use of it. > >> 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. Makes sense. > >> 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. Right. I hope we can discuss this more and make it part of the spec. Maybe a Pace is needed? > >> 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. Who keeps track of fixes to the spec? I'm assuming Joe Gregorio does. Hopefully he catches this thread. > >> 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. Agree. > >>> 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. Bummer. Sometimes working groups hold issues to be out of scope, but then again sometimes they change their minds and take on more work (wow, did I just say that? ;)). Is there any possibility that this could be re-opened for discussion once more. I believe that if APP will become the protocol that makes the Web read-write again, it doesn't make sense to have parts of it specification read-only and be left up to the implementation to do. Now, I totally understand the need to rule some stuff out of scope such as categories, user management and others. But collections are central to the protocol. Maybe a little effort would be worth the time. > >> Regards, >> >> Elias Torres >> http://torrez.us/ >> >> > >
