- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 21 Jun 2000 16:49:44 -0500
- To: "Simon St.Laurent" <simonstl@simonstl.com>
- CC: xml-uri@w3.org
"Simon St.Laurent" wrote: > > At 12:08 PM 6/21/00 -0500, Dan Connolly wrote: > >In particular, if the user chose a namespace name beginning > >with http:, you can infer that a description of/representation of > >the resource identified by that URI is generally available on demand. > > Could you explain exactly where such an inference comes from? [Oops... neglected to cite sources again...] I think so... > It's not in the XML in Namespaces specification. Right... the namespaces spec doesn't say how any URIs, let alone HTTP URIs, work. > It's not (so far as I can tell) in RFC 2616. > > I can't see anything resembling such a claim in RFC 2396. Those are indeed the relevant specs: "The URI syntax consists of a sequence of components separated by reserved characters, with the first component defining the semantics for the remainder of the URI string." http://www.ietf.org/rfc/rfc2396.txt "The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (section 5.1.2)." -- http://www.ietf.org/rfc/rfc2616.txt aka http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 (other related arcana include the IANA registry of URL (sic) schemes ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes and the registration BCP http://www.ietf.org/rfc/rfc2717.txt) Hmm... I suppose I don't quite have a logically compelling argument based on the text of the specs. I can't quite conclude that a GET request for that URI should succeed. Thanks for the insightful question... I suppose xmlns="http://..." could mean something more like <form action="http:..."> or <base href="http://..."> where there markup around the URI suggests using it for something other than getting a representation. But even in those cases, copying the URI out of the HTML source and pasting it in the Address: field of your browser should do something reasonable: most useful form action URIs return the form document itself, for example. This is suggestive, though not precisely compelling: "The methods GET and HEAD MUST be supported by all general-purpose servers." -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1 I think it's clearly a useful best practice, if only for debugging, that folks can use the namespace URI to get some content that helps them figure figure out the intended usage of the namespace name... i.e. to use xmlns as a standarized syntax for this idiom: "<docs> -- A URL, points to the documentation for the format used in the RSS file. It's probably a pointer to this page. It's for people who might stumble across an RSS file on a Web server 25 years from now and wonder what it is." -- http://backend.userland.com/rss091 More motivation... Tim Bray says: "Now, if I'm a good citizen, and want other people to be able to do things with my "x" elements, I ought to publish a prose description of what this element is all about, an open-sourced reference implementation of software that does something useful with it, and a schema (in descending order of importance IMHO but reasonable people may differ on that :))" -- http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0774.html One way to make such prose/code/schema available and easy to find is to return it when somebody accesses the namespace name; use content negotation to make all three available there, or return one and have it link to the others, or whatever... but surely any reasonably direct path like that is more useful than forcing receivers to exhaustively searching the web, using something like altavista's backlink feature, no? > This 'inference' is certainly not suggested by the many examples of > 'namespaces best practices' from the XML-dev list and other community > resources I pointed out earlier in this discussion. I find that very unfortunate. Does anybody maintain such a document? I'd like suggest that they change it. Are there any guides that actively discourage folks from supporting GET access on namespace names? I'd surely like to change those. > I see no cause for making such inferences, and would suggest that they be > withdrawn until such time as they are specified formally. We have a clear disagreement about what best practices are (unless, by some happy chance, I've conviced everybody ;-) I wish people would stop issuing namespace names without backing them by anthing more than 404 errors, but I'm not about to ask that they stop doing it until there's a formal spec for doing it. I don't see how that gets us very far. In 1989/1990, it would have gotten us no Web at all. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 21 June 2000 17:54:21 UTC