<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 2/10/2010 3:55 PM, Martin Atkins wrote:
<blockquote cite="mid:4B72668C.9070706@degeneration.co.uk" type="cite"><br>
Brett Zamir wrote: <br>
<blockquote type="cite">Hi, <br>
<br>
Internet Explorer has an attribute on anchor elements for URNs:
<a class="moz-txt-link-freetext"
href="http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx">http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx</a>
<br>
<br>
This has not caught on in other browsers, though I believe it could be
a very powerful feature once the feature was supported with a UI that
handled URNs (as with adding support for custom protocols). <br>
<br>
Imagine, for example, to take a link like: <br>
<br>
<a href=<a class="moz-txt-link-rfc2396E"
href="http://www.amazon.com/...%28shortened%29....">"http://www.amazon.com/...(shortened)...."</a>
urn="isbn:9210020251">United Nations charter</a> <br>
<br>
</blockquote>
[snip details] <br>
<br>
I like what this proposal achieves, but I'm not sure it's the right
solution. <br>
<br>
Here's an attempt at stating what problem you're trying to solve
without any specific implementation: (please correct me if I
misunderstood) <br>
<br>
* Provide a means to link to or operate on a particular artifact
without necessarily requiring that the artifact be retrieved from a
specific location. <br>
<br>
* Provide graceful fallback to user-agents which do not have any
specialized handling for a particular artifact. <br>
<br>
</blockquote>
Yes, exactly.<br>
<blockquote cite="mid:4B72668C.9070706@degeneration.co.uk" type="cite">This
is
different to simply linking to a different URL scheme (for example,
linking a mailto: URL in order to begin an email message without
knowing the user's preferred email provider) because it provides a
fallback behavior for situations where there is no handler available
for a particular artifact. <br>
<br>
</blockquote>
Yes. But note also that it would be possible to have the @protocol
attribute be, for example, be used for already frequent protocols like
mailto:, and the @href be http: . Or, to use a URN, the protocol could
be urn:isbn:... and the
@href could be http, etc.<br>
<br>
Since 'href' also links to a protocol, it might be more
clear for the proposed attribute to be called something like
@defaultProtocol.<br>
<br>
<blockquote cite="mid:4B72668C.9070706@degeneration.co.uk" type="cite">==
Example
Use-cases == <br>
<br>
* View a particular book, movie or other such product without favoring
a particular vendor. <br>
<br>
* View a map of the location for particular address or directions to
that address without favoring a particular maps provider. <br>
<br>
* View a Spanish translation of some web document without favoring a
particular translation provider. <br>
<br>
* Share a link/photo/etc with friends without favoring a particular
publishing platform. (i.e. generalizing the "Tweet This", "Share on
Facebook", class of links) <br>
<br>
</blockquote>
<br>
Yes. This would of course depend on the protocols existing. For
example, XMPP as an open protocol, might work for your last examples
if those services were actually using XMPP. And your other examples
would also be excellent use cases.<br>
<br>
<blockquote cite="mid:4B72668C.9070706@degeneration.co.uk" type="cite">==
Prior
Art == <br>
<br>
=== Android OS Intents === <br>
<br>
The Android OS has a mechanism called Intents[1] which allow one
application to describe an operation it needs have performed without
nominating a particular other application to perform it. <br>
<br>
Intents are described in detail here: <br>
<a class="moz-txt-link-freetext"
href="http://developer.android.com/guide/topics/intents/intents-filters.html">http://developer.android.com/guide/topics/intents/intents-filters.html</a>
<br>
<br>
An intent that does not identify a particular application consists of
the following properties: <br>
<br>
* Action: a verb describing what needs to be done. For example,
"view", "edit", "choose", "share", "call". <br>
* Object: the URI of a particular thing that the action is to be done
to. This is not specified for actions that apply only to a class of
object, such as "choose". <br>
* Object Type: the MIME type of the Object, or if no particular Object
is selected a concrete MIME type or wildcard MIME type (e.g. image/*)
describing the class of object that the action relates to. <br>
<br>
A process called "Intent Resolution" is used to translate an abstract
intent like the above into an explicit intent which nominates a
particular handler. <br>
<br>
Often when applications use intents a UI is displayed which allows a
user to choose one of several available applications that can perform
the action. For example, the built-in photo gallery application
provides a "Share" command on a photo. By default, this can be handled
by application such as the email client and the MMS application, but
other applications can declare their support for intents of this type
thus allowing plug-in functionality such as sharing a photo on
Facebook. <br>
<br>
</blockquote>
<br>
That's an interesting consideration.<br>
<br>
I think some behaviors should be necessarily limited with links (as
they are in HTTP disallowing a link to make a POST or PUT request or
upload a form (without JavaScript at least))--so that, e.g., spam links
don't cause users to accidentally do things they didn't want to do. So
side-effects should probably not occur (like "share" at least), unless
it was merely, as in your use cases with Twitter/Facebook to lead to a
UI control confirming that you wanted to share.<br>
<br>
Unlike URNs, a regular protocol could already handle the use cases you
mention, and perhaps the Intents mechanism could itself be made into a
protocol: e.g.,:<br>
<br>
android:intents;action=CALL;data=tel:123-555-1212<br>
<br>
Being that experimentation here is fairly early on, and being that
there may be too many types of fundamental actions/data/etc. to agree
would be useful for the whole web (at least at this stage), I'd think
that allowing protocol innovation should be enough for now. As HTML5 is
now doing in co-opting various existing practices, HTML6 could also
consider specializing support for particular protocols down the line if
they were found to be worthy of being obligatorily supported.<br>
<br>
<br>
<blockquote cite="mid:4B72668C.9070706@degeneration.co.uk" type="cite">===
Internet
Explorer "urn" Attribute === <br>
<br>
Internet Explorer supports a non-standard attribute on the "A" element
called "urn", which accepts an URN identifying some resource. <br>
<br>
It is described in detail here: <br>
<a class="moz-txt-link-freetext"
href="http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx">http://msdn.microsoft.com/en-us/library/ms534710(VS.85).aspx</a>
<br>
<br>
It is not apparent that this attribute causes any behavior in the
browser itself. It is possible that this is exposed to browser
extensions in some way to allow them to overload the behavior of a link
which identifies a particular class of resource. <br>
<br>
It does not seem that this attribute has achieved wide author adoption
nor wide application support. <br>
<br>
</blockquote>
Yes, that is correct on all counts. But like perhaps Esperanto (or
international English, etc.) not catching on, I think the fault does
not lie in the utility of the idea, but in its inadequate
standardization and implementation. If the browser doesn't do anything
special with the attribute, then there is little incentive for website
creators to make use of it. It seems that the "urn" attribute
documentation doesn't even make explicit the idea that it could be used
for default processing, so I'd at least like to see this documented as
a potential use, or rather, see the more comprehensive @defaultProtocol
document it. It'd be great if there could be default handling behavior
specified (akin to using a new protocol inside "href"), but if it is
too late in the game, it'd be nice to at least have the attribute with
a suggested behavior, letting the browsers add support if they wished.<br>
<br>
<blockquote cite="mid:4B72668C.9070706@degeneration.co.uk" type="cite">---------------------------
<br>
<br>
Please reply with any other use cases and prior art you have. <br>
</blockquote>
<br>
I don't know of any other prior art, except that protocol handling is
already in
<a class="moz-txt-link-freetext" href="http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler">http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler</a>
.<br>
<br>
I think there are any number of use cases--some of which may crop up in
the future; your list I think already gave a good overview of some
possibilities. There is the one I already mentioned for a Wikipedia or
Wikipedia-like protocol to reference concepts, people, or things in a
generic way, with other encylopedias or resources being potentially
registerable to handle such resources. I chose Wikipedia because of its
popularity, openness, and flexibility--no need for waiting around for
IANA to approve a new concept. That adds some challenges with names
being in flux as pages are deleted, redirected, merged, etc., but I
think could still be very useful. Other encyclopedias could use their
own protocol, or be made to work with Wikipedia as a base, letting
their users (and Wikipedia users) view an article where they please.
(Of course, it'd be nice if there were an open API so that one could
easily query to find out whether the handler turn up any results; see
my suggested JavaScript below.)<br>
<br>
Maybe another similar use case could be a protocol which looked for
commentary or information on a given webpage--e.g.,:<br>
<br>
commentary:?url=<a class="moz-txt-link-freetext" href="http://yahoo.com">http://yahoo.com</a><br>
<br>
or<br>
<br>
urn:commentary:<a class="moz-txt-link-freetext" href="http://yahoo.com">http://yahoo.com</a> (escaped as needed by URN syntax)<br>
<br>
...could find out info about what users had to say about Yahoo.<br>
<br>
As yet another example, I just recently proposed to the Unicode mailing
list that a protocol be adopted to specify a particular Unicode
character, range of characters, or searched subset. While this might
not be something the average user would clamor for, I was hoping to get
standardization on the custom protocol I designed to work with my
Unicode browsing Firefox extension, (at
<a class="moz-txt-link-freetext" href="https://addons.mozilla.org/en-US/firefox/addon/5235">https://addons.mozilla.org/en-US/firefox/addon/5235</a> )--a protocol which
would let you choose how you wanted to view a particular Unicode
character--e.g., to get description info, meta-data, equivalent
entities, etc.<br>
<br>
While it may seem desirable to be more specific--and indeed it often
is--sometimes there is benefit in being able to be vague. For example,
when clicking on such a
Unicode "link", it may be desired to leave ambiguous what the user
should do
with the content. For example, one registered handler might simply
display the
character's authoritative name. Another use might be to display the
character in a chart along with other characters in that range. As in
language, sometimes ambiguity can be a good thing, letting your user
come to their own conclusion/take their own path.<br>
<br>
If I understand URNs correctly, this ambiguity seems to be closer to
what a URN represents. It doesn't seem to imply an action, just a name.
While that might not always be clear, if the particular terminology
implied an action, it would seem to me that this is more generic than a
protocol which can have say a query string with variables including
actions, objects, etc.<br>
<br>
That being said, I'd really like to see any protocol work here (and
urn: seems it can also be used in protocol form anyways).<br>
<br>
Actually, maybe it should even be @defaultProtocols with say
white-space separated protocols occurring in order, to allow, say, one
to check for support for "tel:", and if none, then "mailto:", and if
none, then href to a contact form.<br>
<br>
<blockquote cite="mid:4B72668C.9070706@degeneration.co.uk" type="cite">I'm
particularly interested to see whether Android's (verb, object) tuple
is actually required or whether the single object as afforded by your
proposal -- and by the existing design of registering handlers for
particular URL schemes and MIME types -- is sufficient for the
use-cases at hand. <br>
</blockquote>
<br>
As far as the existing design of registering handlers, while I think
that should be all right (e.g., as already at
<a class="moz-txt-link-freetext" href="http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler">http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler</a>
and also described at
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en/Web-based_protocol_handlers">https://developer.mozilla.org/en/Web-based_protocol_handlers</a> ), I think
it'd be nice to be able to see additions to say the navigator object or
<a/> (if not onclick events):<br>
<br>
<a href=<a class="moz-txt-link-rfc2396E" href="http://amazon.com...">"http://amazon.com..."</a> defaultProtocol="urn:isbn:..."
onclick="check(event);">Some book</a><br>
<script><br>
// We must rely on "onclick" since older browsers wouldn't support a
handler like "onDefaultProtocol" anyways.<br>
// The following demonstrates some potentially useful properties for
the event:<br>
function check (e) {<br>
if (!<b>navigator.defaultProtocol</b>) {<br>
if (!confirm("Your browser doesn't support generic protocols;
would you like to be redirected to "+this.href+"?") {<br>
e.preventDefault(); // Here we can prevent the regular
'href'<br>
}<br>
}<br>
else if (!<b>navigator.defaultProtocol.handlers</b>) { // or
requiring a key to a specific scheme?<br>
alert("Although your browser supports generic protocols, you do
not have any handlers registered for"+<b>this.defaultProtocol.scheme</b>);
//
"for urn".<br>
if (!confirm("Would you like to be redirected to the default
URL?") {<br>
e.preventDefault(); // Here we prevent the defaultProtocol
(and href) from proposing a dialog to find a protocol; there could
either be <br>
// special syntax added to allow jumping over the
defaultProtocol to the default 'href', or the JavaScript could simply
set <br>
// window.location. The latter would probably be enough.<br>
}<br>
else { window.location.href = this.href; }<br>
}<br>
else {<br>
// Since some handlers might need to make a network connection
to figure out whether they can not only handle the scheme, but also<br>
// the particular content (like for a specialized bookstore
which only recognized certain ISBNs), maybe it should also be possible
to have<br>
// a selection hierarchy order, such that one could activate
checking:<br>
if (!<b>navigator.defaultProtocol.handlers.supports</b>(this.defaultProtocol))
{<b><br>
</b> alert("Unfortunately your registered protocol handlers
cannot support this particular protocol instance.");<br>
e.preventDefault();<br>
}<br>
// We might allow script access to the names of the protocol
handlers, but not allow invoking of a particular handler since it might
violate the user's wishes; however "selected.name" could be advanced to
the first capable handler found by the supports() check above<br>
alert("We will now open "+<b>navigator.defaultProtocol.handlers.selected.name</b>)+"
with "+<b>this.defaultProtocol</b>; // e.g., "...will now open
UsedBooks with urn:isbn:..."<br>
}<br>
}<br>
</script><br>
<br>
While the above might be very useful, I don't think it would be
critical--and no doubt others may find better ways of implementing....
The main thing I'd like to see is at least some attribute that
justifies giving default behavior to a protocol for handling generic
data and which could override 'href' if the user agrees.<br>
<br>
Brett<br>
<br>
</body>
</html>