W3C home > Mailing lists > Public > www-tag@w3.org > January 2012

Re: HTML5 proposes introduction of new family of URI schemes

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Fri, 20 Jan 2012 18:50:48 +0900
Message-ID: <4F1938F8.5090607@it.aoyama.ac.jp>
To: Noah Mendelsohn <nrm@arcanedomain.com>
CC: Robin Berjon <robin@berjon.com>, "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>
Hello Noah,

On 2012/01/20 4:37, Noah Mendelsohn wrote:
>
>
> 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]).

I think I tried to explain this to you, but the intent is NOT to have 
new schemas with web+ in parallel to already existing ones. The intent 
is just to identify the fact that a *totally new* scheme can be used in 
Web applications with a web+ prefix. For existing schemas, the current 
whitelist is supposed to cover those that are suitable for use with Web 
applications. So this point is largely moot.

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

Using a web+ scheme does *NOT* mean that these schemes are intended for 
exclusive use with Web applications. That would indeed be a bad idea. 
The web+ is just a sign that tells the Web browser that if a Web page 
asks the Web browser to be the responsible "handler" page for that 
scheme, the Web browser is allowed to ask the user. The same applies for 
schemes on the whitelist.


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

The question is not what mechanism to use to map from one URI/IRI (e.g. 
a mailto: URI/IRI) to another (e.g. a http://mail.google.com/... or 
whatever). The current %s placeholder is cruder than URI templates, but 
is totally sufficient for the case that all URIs/IRIs of a scheme are 
handled by the same Web application.

The question is "what schemes are browsers allowed or not to let Web 
applications handle (after user application), and how can this be done 
for new schemes automagically".

With all this, I'm not trying to defend the web+ prefix, I'm just trying 
to help people understand why it was created.


Regards,   Martin.
Received on Friday, 20 January 2012 09:51:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:44 GMT