Re: XBL Namespace uses the data: scheme

* noah_mendelsohn@us.ibm.com wrote:
>Which begs the questions:  what sorts of information should be in a URI, 
>and who should or shouldn't depend on it being there?  This might be the 
>time to remind everyone that the TAG has been working on just those 
>questions under the banner metadataInURI-31 [1].  We have a draft finding 
>[2], which as of the last TAG F2F is quite close to final.  If this 
>discussion is going to turn to what should or shouldn't be encoded in the 
>text of a URI, I suggest giving the draft a look first.  Thanks!

>[1] http://www.w3.org/2001/tag/issues.html#metadatainURI-31
>[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31

Let's see. The resource locator of the resource is poorly chosen, the
document then incorrectly claims to make correct use of RFC 2119 terms,
the first constraint is incorrectly established (in the example given,
the problem is that inferring authoriative content type information
from the HTTP resource locator is not licensed by an applicable spec)
in addition to being obvious ("Don't depend on what's not guranteed").

The first good practise is rather odd; it's introduced by claiming that
the scheme component of a resource identifier is metadata "peeked" from
the resource identifier, and attempts to suggest making, say, a browser
that supports only HTTP and therefore only HTTP resource locators is
somehow bad (which it is not). It then repeats justifaction for the 
constraint discussed above. Frankly, I have no idea what's this trying
to say.

The next good practise is obvious again ("Don't do something unless
willing to accept the consequences") though I like how it's introduced
by "Web users act on guesses about URIs all the time"; this happens e.g.
if I call you and ask you to go to "http://example.org/weather/Boston"
and tell me what's on that page. If you then infer I might be wondering
about the weather in Boston, you are acting contrary to "Agents making
use of URIs SHOULD NOT attempt to infer properties of the referenced
resource."

Section 2.4 is a bit funny. I am unaware of where the HTML spec makes
any mention of what is inferred, and "The same HTML Form is also a
computer program, executable by the browser, ..." well, that's sure a
good one for the .signature file.

Section 2.5 apparently contradicts "Avoid software dependencies on
metadata in URIs." in that it suggests "Even if it does not document
this policy publicly, example.org's own Web servers can safely depend
on it" implying it's okay to do that. I am unsure what good practise 
is established here, the text explains an option, it does not make
any suggestion.

Section 2.6 is paradox, http://example.org/123Hx67v4gZ5234Bq5rZ is
obviously not intended for direct use by people and therefore the
good practise does not apply. To make it meaningful you would have
to root the good practise as usability concern and base it upon user
goals; in other words, URIs that people want to make direct use of
are to be made usable by people (which again is obvious).

It seems http://www.w3.org/2001/tag/doc/metaDataInURI-31 is intended
to be used directly by people, yet it is not easy to understand (why
"2001"? Why "doc"? Why "31"?) and consequently not suggestive of the
resource actually named (too much noise to determine the signal).

The good practise in 2.7 is implied by the one in 2.6, it is harmful
if interpreted incorrectly, and poorly extroduced (resource locators
locate resources, they do not convey metadata about a resource as 
claimed in the extroduction). I also note that there is little if any
consensus about this; the principle builds upon the assumption that
it's a bad idea to change resource locators as the resource changes;
you can equally well say that resources should never be changed, or
that redirects should be used so users of old resource locators can
easily become aware of new resources and their locators.

It seems the References section violates the "Consistent URI usage"
good practise and the document its own "Resource metadata that will
change SHOULD NOT be encoded in a URI." "URIs" have been obsoleted
many, many years ago, only a few confused people want them to stay.

So in conclusion I am unsure why we should look at the draft? There
is extraordinarily broad agreement that W3C's so-called "namespace 
policy" makes no sense whatsoever, I don't think there is anything
to be discussed here really. Many acceptable schemes

  * urn:w3c:xhtml
  * xmlns:...
  * http://ns.w3.org/xhtml
  * http://namespace.w3.org/xhtml/
  * ...

have been proposed in the past, it's simply time to discontinue the
current malpractise.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 29 June 2006 22:50:36 UTC