AWWW Last Call Comments

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.

------------------
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

Received on Thursday, 26 February 2004 14:25:02 UTC