On 14/01/2006, at 8:07 AM, Sam Ruby wrote:
PaceAnchorSupport
+0
PaceCategoryListing
+0 I don't mind if this is done as an extension.
PaceClarifyMediaResourceLinks
If the interpretation is correct, I think these editorial changes are
required. Implementing 07, I didn't have that interpretation, though.
PaceClarifyTitleHeader
+1 if we keep Title
PaceDifferentRelValue
+1 while 'alternate' makes sense for the main page of a blog, I've
always felt uneasy using 'alternate' on an individual entry that
points to the full feed.
PaceDontUseContentSrc
+0 makes sense to me but I haven't followed the discussion of pros
and cons enough
PaceEditLinkMustToMay
+1
PaceExamples05
The second example needs to be updated to collection paging.
The third example is already in 07.
Both the first and third example have content in the 201 response but
the spec itself never says what that content should be. Without
reading the example, I assumed the 201 response would have empty
content. In the third example, an atom entry is returned when media
is posted. If this is what is expected of APP servers, it needs to be
made more explicit in the spec prose itself.
PaceLinkIntrospection
-0 I see the introspection documentation location as the entry point
to the APP server and I don't really see why clients need help in
automatically locating it.
PaceMissingDraftHasNoMeaning
-0 I have no problem with 07 on this topic.
PacePreserveForeignMarkup
+1
PaceRemoveMemberTypeMust
PaceRemoveMemberTypePostMust
+1 (to both)
PaceRemoveTitleHeader
-0 If we keep Title, I think we need Author as well. I'm unclear on
the status of editing metadata, though, so I'm not sure whether we
can remove Title.
PaceRequestURI
+0 open to alternative proposals to achieve the same thing
PaceServiceMayHaveWorkspaces
PaceServiceShouldHaveWorkspaces
Prefer may (+1) over should (+0)
PaceSimpleIntroduction
looks withdrawn
PaceSparqlLink
-1 I like it but not for this spec
PaceTitleHeaderOnlyInMediaCollections
+1 if we keep Title header
PaceTwoPrimaryCollections
-0
PaceUseLinkHeaders
looks withdrawn
PaceWorkflows
In general, I'm in favour of workflows however, draft meets the 80-20
case. Could "draft" be viewed as a simple visibility flag and
workflow be added later? I'd rather have draft than nothing.
PaceWorkspaceMayHaveCollections
PaceWorkspaceShouldHaveCollection
Prefer may (+1) over should (+0)
James
