Re: AWWW Last Call Comments

On Thu, 2004-02-26 at 14:23, Kendall Clark wrote:
> Through my work at UMD's Mindlab and XML.com (as well as trying to write a
> chapter on web architecture for the REST book I'm doing for O'Reilly), I've
> been spending a lot of time since December with the AWWW document.
> 
> I've found a few issues that I want to present formally as Last Call
> comments.  I've tried to summarize the issues below, and in many cases I've
> included links to more substantive discussions (in which, in some cases,
> there is some prose which is more suited to a generalist audience than to
> the TAG, for which my apologies).
> 
> If some of these sound, well, crabby, I apologize; my intent has simply been
> to take the document as seriously as it was offered. I've tried to raise
> specific issues tied to concrete textual problems, rather than more general
> complaints about tone or intent. 
> 
> I'll be at the TAG public meeting on Tuesday in Cannes, and I'd be happy to
> elaborate on any of these if that would be helpful.

Kendall,

Thank you for your comments (and your articles). I anticipate the TAG
will review them next week.

 - Ian

> ------------------
> Last Call Comments
> ------------------
> 
> 1a. Fragment Identifier Semantics
> 
> The new way of explaining fragment identifier semantics -- that is, talk of
> primary and secondary resources -- is, in my view, very weird. I amplify
> this claim at <http://monkeyfist.com/kendall/awww-issues/frag1.txt>.
> 
> While I suspect that the older language for describing these semantics
> had its own problems, I would be happier either with (1) its return or
> (2) some further amplification or clarification of the existing
> language.
> 
> 1b. Conflicting Secondary Resources
> 
> I find this discussion in AWWW totally underdetermined. I discuss this
> at length at <http://monkeyfist.com/kendall/awww-issues/frag2.txt>.
> 
> 2. What Kinds of URI Ambiguity Are There?
> 
> AWWW abjures URI ambiguity; but in trying to think carefully about this,
> I've realized that it's important to distinguish two kinds of URI ambiguity:
> diachronic and synchronic. The AWWW only addresses the former kind, and I
> think it should address the latter kind, too.
> 
> Diachronic URI ambiguity is the case where at time T, URI U identifies
> resource R; but at time T2, U identifies R2.
> 
> Synchronic URI ambiguity can arise from "URI overloading" via content
> negotiation. Consider a URI U that identifies a magazine article
> resource, which is available in three different data formats, via
> con-neg: HTML 4, the XML variant of DocBook, and plain text. Consider,
> also, that via con-neg one can get an RDF representation of the
> article's metadata (say, the standard DC terms which apply to it). In
> this (common!) case, I suggest that U is synchronically ambiguous:
> which resource does it really identify, the article or the article's
> metadata? They aren't the same resource, though they are related; this
> synchronic URI ambiguity is as problematic, if not more so, than the
> diachronic type.
> 
> I'd like to see some language in the AWWW about avoiding synchronic
> ambiguity by avoiding the "URI overloading" mistake with content
> negotiation. 
> 
> 3. Willy-Nilly Resource Change
> 
> The AWWW says that one may conclude that agents or representations are
> each referring to the same resource if they are using identical URIs.
> But that's problematic; it suggests that the relation between
> resources and URIs is in some sense timeless and static. Once a URI
> has been coined to identify a given resource, it can only ever
> identify precisely that resource; else, we have to embrace the
> willy-nilly change problem.
> 
> The willy-nilly change problem really bothers me; this is probably
> more pointed in the SemWeb 'social meaning' context; but even if so,
> there should be some indication in the AWWW that other people's URIs
> can change *radically*, ad-hoc'dly, and with neither forewarning nor
> warning. Yes, the AWWW implies this, but I'd be happier if it stated
> it outright.
> 
> (I think what I'm calling "willy-nilly resource change" is an
> implication of the issues about ownership and authority raised by
> Peter Patel-Schneider. In some sense, then, my objection is parasitic
> upon his. If in responding to his objection the TAG substantively
> changes the AWWW -- which I doubt will happen, for what it's worth --
> some such change may moot my objection here. If it does not
> substantively change the language about authority & ownership, then
> my objection is that it should warn people about the resulting
> willy-nilly resource change problem.)
> 
> 4. Hypertext Issues
> 
> 4a. Hypertext Good Practice Redundancies 
> 
> There seems to be a redundancy between two of the good practices in the 
> discussion of hypertext. (Or, alternately, I simply fail to see the 
> difference(s) which justify the distinction.)
> 
> The first good practice says, in my paraphrase, that (1) good
> representation types allow users to make links to other resources and to
> parts of representation-states of resources.  The second good practice
> says, again in my paraphrase, that (2) good representation types allow
> users to make "Web-wide" links rather than merely "internal document"
> links.
> 
> Aren't these redundant?  A link to "other resources" just is a link to
> something else on the Web or to a resource in some other information system
> which the Web encompasses.  In other words, the reasonable reading of the
> first good practice is that data formats that allow links to other
> resources and to parts of representation-states are better than ones that
> don't, while the reasonable reading of the second good practice is that
> data formats should allow links to resources on the Web and not just to
> parts of representation-states.  I fail to see the distinction which makes
> a difference here.
> 
> If not precisely redundant, it seems that (2) is obviously and trivially
> entailed by (1), so we really only need (1).  Of course, perhaps there's an
> aspect I'm missing completely; if so, could it be make more obvious?
> 
> 4b. "Expected UI Paradigm"?
> 
> The fourth good practice says good representation types allow users to make
> hypertext links when "hypertext is the expected user interface paradigm".
> 
> Surely the AWWW also wants to say that for those kinds of web application
> or scenario -- Service Oriented Architecture and Semantic Web being the two
> obvious examples -- where hypertext is not the "expected user interface
> paradigm", by virtue of the fact that there really isn't a UI per se, one
> still wants to prefer representation types which allow users to make
> hypertext links between resources.  REST and SOAP and RDF and WSDL and a
> lot of other fun stuff works precisely because -- even in the absence of
> any human-facing UI -- what's happening is that messages are being passed
> around between machines, some of which contain assertions about resources,
> and they are messages which contain hypertext links to other resources.
> 
> The real problem here is that there is no real formalization of "hypertext
> link" in the AWWW. If it means A-HREF links simpliciter, then my point
> about SOA and Semantic Web exceptions to this practice is unmotivated and
> null.  But if, as seems likely from Section 4.5.2.  Links in XML,
> "hypertext links" encompasses any link mechanism (that is, XLink and
> friends) whereby HTTP URIs identify resources with which agents may
> interact with the resources-states thereof, then something like my point is
> needed.
> 
> That is, in the weakest form, good representation types allow users to make 
> hypertext links in many types of applications, but especially when 
> hypertext is the expected UI paradigm. I would be happier with a stronger 
> form of the claim: good representation types allow users to make hypertext 
> links. Period.
> 
> 5. Silent Error Recovery Always Harmful?
> 
> I don't agree with the exceptionless form of this principle.  I think one
> can imagine silent error recoveries which aren't harmful.  I suggested an
> amended version: silent error recovery is harmful if, and only if, it does
> some harm beyond mere failure to notify; or, put better: mere failure to
> notify isn't always a harm. (I'd be just as happy with the smallest 
> possible weakening of the principle, something like: "Silent recovery from 
> error is usually [or "typically" or "often"] harmful."
> 
> 6. Separating Presentation From Content
> 
> This is often harder than the AWWW lets on, and sometimes it's simply not 
> possible at all. I think the language should be modulated to reflect that 
> reality.
> 
> Further discussion, with concrete suggestions for change, is at 
> <http://monkeyfist.com/kendall/awww-issues/prescon.txt>.
> 
> 7. More Ambiguity 
> 
> "the ambiguous use of terms" is ambiguous; and, contrary to the AWWW's
> (fairly casual, of course) claim, ambiguity does *not* always impose a cost
> in human communications -- a research result demonstrated by UK cognitive
> scientists, among others.  (If you want the full cite to this paper on
> CiteSeer, I can drum it up.)
> 
> 8. Section 3.4.'s Unmotivated Paragraph
> 
> There is a paragraph about URI ownership in Section 3.4, and I can't 
> understand what it's doing there. I would strike or amend it. Full 
> discussion of this issue is at 
> <http://monkeyfist.com/kendall/awww-issues/para.txt>.
> 
> 9. "Safe" and "Unsafe" Interactions
> 
> I think I "know what you mean", but I really really hate the way this 
> discussion is framed in the AWWW. I consider other ways of talking about 
> this at <http://monkeyfist.com/kendall/awww-issues/safety.txt>.
> 
> 10. Out-of-phase frag-id wordings in "Good Practice: Link Mechanisms"
> 
> There are a few places in the AWWW where the language is out of phase with
> the new primary-secondary resource talk.  This falls under wordsmithing and
> copy editing, but these out-of-phase bits really need to be fixed, since 
> the issue is complicated and there have been at least two different ways of 
> describing the semantics.
> 
> 11. The "great power" of URIs and their "vastness of choice"
> 
> I find this sentence, from Section 2.  Identification, to be garbled at
> best.  I discuss in some detail some of the issues it raises and implies in
> <http://monkeyfist.com/kendall/power.txt>.
> 
> 12. Needless Propagation of URIs?
> 
> I think this, as stated, is too strict. Further discussion at 
> <http://monkeyfist.com/kendall/awww-issues/prop.txt>.
> 
> Thanks to my colleagues at UMD's MIND Lab, especially Bijan Parsia and Jim
> Hendler, and O'Reilly's Edd Dumbill and Simon St.Laurent for discussions of,
> and reasons to discuss, these issues.
> 
> Thanks,
> Kendall Clark
-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447