UddpIssues

Jonathan's notes on issues raised with the document at http://www.w3.org/2001/tag/doc/uddp/ - both substantive and editorial. I know this is a wiki but I would prefer if you ask me (Jonathan Rees, rees at mumble.net) to make changes to this page rather than just editing directly - that will make it much easier for me to keep track of the current state of play for each issue.

The basis for "substantive" vs. "editorial" classification is whether a change to the document on the given issue is likely to lead to different behavior on someone's part in some situation.

The editor's say is not final; the content of the document is up to the TAG.

Certain names occur repeatedly, so they will be abbreviated by initials: JAR = Jonathan Rees, TimBL = Tim Berners-Lee, DB = David Booth.

Substantive

303 has performance problems (2 round trips, first one not cached by some clients), and hash is allegedly an unacceptable alternative. Raised by: Giovanni Tumarello. Disposition: This is TAG ISSUE-57. Change proposal call issued 2012-02-29.

303 is hard to deploy on commodity hosting platforms, and hash is allegedly an unacceptable alternative. Raised by: Harry Halpin, Manu Sporny, Ian Davis, Pat Hayes, et al. Disposition: Grouped with performance concerns, previous issue.

"Is an information resource" is useless, because the Flickr / Jamendo confusion is not addressed. Needs to be either strengthened to "the representation is an instance of the [generic] resource", or removed so that 200 can be used instead of 303 for all resources, not just information resources. If removed, introduce wa:instanceURI so that there's a common way to talk about generic resources. Raised by: Jonathan Rees, Pat Hayes. Disposition: This doesn't directly have to do with ISSUE-57, but JAR intends to prepare change proposals during upcoming www-tag discussion (but may run out of time - in the meantime see "either strengthen or retract httpRange-14(a)").

URI vs. IRI - which to use in the document? Raised by: David Booth. Disposition: JAR agrees it needs addressing, will defer to TAG.

Narrow scope to http: URIs. Raised by: DB. Disposition: Editor disagrees.

Whether to couch the presentation as an imperative protocol instead of declarative "is a nominal URI documentation carrier". (Editor considers this substantive because an imperative treatment is likely to be more prescriptive than a declarative treatment, restricting client freedom.) Raised by: DB. Disposition: Editor disagrees.

Maybe introduce a table of HTTP status codes per DB's document. Raised by: DB. Disposition: Editor disagrees, does not understand, unsure of benefit.

Editorial

Title - say "URI documentation" instead of just "documentation" - can be misread. Raised by: DB. Disposition: Editorial action: JAR tends to agree, added a second "URI" to the title. The title will need to be reconsidered later on in the process.

Remove disclaimers about "authoritative" as counterproductive. Raised by: DB. Disposition: editorial action: removed one occurrence of "authoritative", qualified a second occurrence with the adjective "objective".

The "nominal" vs. actual distinction is still perhaps not clear. Raised by: DB. Disposition: DB does not understand what was intended, so text may have been unclear despite efforts. Have modified the explanation in an attempt to clarify, see "for example, the representation might be empty".

Request to mark sections as "normative" and "non-normative". Raised by: DB. Disposition: Editor's response: AWWW and TAG findings do not make this distinction, not appropriate in an architectural recommendation, judged too formal for this document.

Terminology "URI definition" to "URI documentation". Raised by: DB. Disposition: "Definition" discouraged by Jeni Tennison and other reviewers, editor agrees.

Terminology "local identifier" vs. "fragment identifier". Raised by: DB. Disposition: "local" requested by TimBL, agreed by JAR.

Terminology "target URI" vs. "probe URI". Raised by: DB. Disposition: Editor prefers editor's choice.

Better to couch some of the content as "Best practices" or "good practices"? Raised by: DB. Disposition: Editor opposed.

Rewrite the document from the URI owner's point of view, or prepare an additional document that is so. Raised by: Mo McRoberts Disposition: Editor feels that if the receiver's behavior is determined then (a) the specification is likely to be more complete and unambiguous and (b) the sender's and URI owner's behavior will follow. But such an approach might be good to take in a separate document.