Elias Torres wrote: >[snip] >>> 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, ..., */*". >
Not a big deal unless the Accept indicates some value that doesn't include application/atomserv+xml. >>> 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: > Workspaces are a purely organizational construct. They don't "own" collections, they are used merely to group collections into logical sets. Also, thinking about it further, there's nothing in the spec that forbids a collection from appearing twice within a single workspace. <service> <workspace title="..."> <collection xml:lang="en" title="..." href="http://example.org/foo"; /> <collection xml:lang="fr" title="..." href="http://example.org/foo"; /> </workspace> </service> And yes, it is a bit underspecified. The fact that workspaces and collections do not have unique id's has bit me a couple of times now. >[snip] > >>> 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? > Yep. >[snip] >>> >> 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. > Hard to say. - James
