Review of 3-Dec Recipes editors' draft

Introduction: "@@TODO Where is this wiki page?"

I'd proposed [1] that it be topic VocabPublishingRecipes [2] in the ESW wiki
and I have just created that page.  Per [1], I suggest the editorial change

  "The /-editors wish to extend an invitation to any and all to submit-/
    /+Working Group invites contributions of+/ additional bindings for
   non-Apache servers."

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2007Dec/0057.html
[2] http://esw.w3.org/topic/VocabPublishingRecipes

There are several (I counted 3) references to the TAG's resolution
of httpRange-14 all of which cite the 18 June 2005 email to www-tag.
I suggest adding an additional citation to the 4 October 2007 editors
draft TAG finding [3].  (Perhaps the simplest way to do this is to add
[HTTPRANGE14] as a reference and list both the email and the
editors draft Finding as citations in the one entry.  This makes it
easy to update for future versions when, hopefully, the TAG finding
is published.)

[3] <http://www.w3.org/2001/tag/doc/httpRange-14/2007-10-04/HttpRange-14.html>

I also suggest in the next-to-last paragraph of the Introduction where
we cite other documents that we add a citation of the recently-published
Working Draft "Cool URIs for the Semantic Web" [4].  The reference
in Appendix B to the older DFKI version of "Cool URIs" should be
updated to this WD as well.

[4] http://www.w3.org/TR/2007/WD-cooluris-20071217/

Content Negotiation, 6th paragraph just before "Default behavior"
Add a note that though recipes 3, 4, 5, and 6 do accommodate some
client ordering preference in content negotiation, they do not handle
the full HTTP specification. In particular, options such as "q" metrics
are ignored.  We could even add an editor's note explicitly soliciting
community suggestions on how the conditional redirect recipes
could be improved.  (There's a note about these inadequacies in
Recipe 6, pattern 1, the paragraph just before the editors note.
Perhaps some of that language can be included in the Content
Negotiation section.)


When I printed a hardcopy of the document, the longer lines in
each of the blocks of directives were truncated.  I suggest using
'\' continuation lines to break the longer RewriteCond directives
between the test and the pattern.  Some of the comment lines
are similarly truncated and should be wrapped.

isegserv.itd.rl.ac.uk -- I see Ed commented on this, so I'll respond
in a new thread.

Recipe 5, directives:
I suggest changing the comments in the directives from

  "Rewrite rule to serve ..."

to

  "Rewrite rule <n>: serve ..."

(where <n> == 1..4) so that in the 3rd paragraph of Notes we can write:

  "... you can replace /-the first two rewrite rules-//+rewrite rules 1
   and 2+/ with one single rewrite rule:"


Recipe 6 -- the heading omits the rest of the section title shown
in the Table of Contents.  I suggest the phrase "a query service"
in place of "bounded RDF descriptions" in the title.

Recipe 6 -- our example should really use an RDF Class or Property.
For this next WD I'd be happy with an editor's note noting that the
example should be so updated if we don't have time to find a
working alternative at DBLP quickly.  (I could forgive the details
in the specific configuration directives but the paragraph that
noted this example gave TimBL's publications stopped me cold.)

Recipe 6, "@@TODO:   RalphS doesn't like DESCRIBE"
I withdraw my concern.  (I think back in October it was based
on some concern over the status of DESCRIBE implementations.)

References
Add a reference to the Cool URIs Working Draft [4].

Appendix A, second paragraph:  "... for the purpose of such redirects
/+for RDF Class and Property names+/, the response code 303 ..."
(i.e. the 303 redirect does not apply to all PURLs.)

Appendix A, third paragraph, add after the first sentence:
"At the time this Working Draft is being written, an update to the
PURL service is in progress.  We anticipate this update will
address the TAG finding on httpRange-14 and 303 redirects."
(see http://www.oclc.org/news/releases/200669.htm )

Appendix A, Recipe 2a, 2nd paragraph: "N.B. this example does
not strictly conform with the TAG resolution on httpRange-14
because /+as of the date of this Working Draft+/ the purl.org
servers use a 302 redirect code, and not a 303."

Appendix A, Recipe 2a, Notes; regarding the additional HTTP
redirect, we could add

  "This creates an additional HTTP redirect in the dereference
  action, but possibly makes it clearer to the client that attempts
  to dereference vocabulary, class or property URIs all end up
  at  the same place /+and does make the current PURL
  implementation conformant with the TAG httpRange-14 resolution+/."

(at least, I believe it would do so).

Appendix A, Recipe 4a, Step 5: remove ".oclc" from the PURL.

-Ralph

Received on Monday, 14 January 2008 16:15:57 UTC