- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Thu, 19 Jan 2012 14:37:05 -0500
- To: Robin Berjon <robin@berjon.com>
- CC: "Eric J. Bowman" <eric@bisonsystems.net>, David Booth <david@dbooth.org>, "www-tag@w3.org List" <www-tag@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>
On 1/19/2012 11:41 AM, Robin Berjon wrote: > Well except that there are quite a few developers, yours truly included, > who really want this functionality. In fact, as indicated earlier, I > find that some parts of it don't go anywhere near far enough. Robin: I'd be grateful if you could explain why using URI templates, or something similar, to pattern match on existing URIs isn't preferable to matching on URIs matching a special "web+" pattern. The drawbacks to web+ seem to include: * Encourages or even requires people to use new schemes, when other schemes might otherwise have been applicable (seems to be at odds with the admonition in AWWW that creation of new URI schemes is strongly discouraged [1]). * Seems to put the decision as to what client will be used in the wrong place, I.e. with the person or organization that coins the identifier. It should IMO generally be possible to have both Web and native apps handle a given identifier, to change one's mind after the fact, etc. If documents are full of links to "web+xxx:....." URIs, then lots of existing mechanism on the Web doesn't work with them (useless in agents that don't know of the new scheme), and you've committed to a naming convention just because, at this point in time, you think people will be using Web-based implementations. Why not URI templates for both the registrations, and the white/black lists? Then you could use existing schemes like http, and things like mailto wouldn't be special cases. Noah
Received on Thursday, 19 January 2012 19:37:30 UTC