On 2/10/2010 3:55 PM, Martin Atkins wrote:
Brett Zamir wrote:
Hi,
Internet Explorer has an attribute on anchor elements for URNs:
http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx
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).
Imagine, for example, to take a link like:
<a href="http://www.amazon.com/...(shortened)...."
urn="isbn:9210020251">United Nations charter</a>
[snip details]
I like what this proposal achieves, but I'm not sure it's the right
solution.
Here's an attempt at stating what problem you're trying to solve
without any specific implementation: (please correct me if I
misunderstood)
* Provide a means to link to or operate on a particular artifact
without necessarily requiring that the artifact be retrieved from a
specific location.
* Provide graceful fallback to user-agents which do not have any
specialized handling for a particular artifact.
Yes, exactly.
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.
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.
Since 'href' also links to a protocol, it might be more clear for the
proposed attribute to be called something like @defaultProtocol.
== Example Use-cases ==
* View a particular book, movie or other such product without
favoring a particular vendor.
* View a map of the location for particular address or directions to
that address without favoring a particular maps provider.
* View a Spanish translation of some web document without favoring a
particular translation provider.
* 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)
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.
== Prior Art ==
=== Android OS Intents ===
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.
Intents are described in detail here:
http://developer.android.com/guide/topics/intents/intents-filters.html
An intent that does not identify a particular application consists of
the following properties:
* Action: a verb describing what needs to be done. For example,
"view", "edit", "choose", "share", "call".
* 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".
* 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.
A process called "Intent Resolution" is used to translate an abstract
intent like the above into an explicit intent which nominates a
particular handler.
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.
That's an interesting consideration.
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.
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.,:
android:intents;action=CALL;data=tel:123-555-1212
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.
=== Internet Explorer "urn" Attribute ===
Internet Explorer supports a non-standard attribute on the "A" element
called "urn", which accepts an URN identifying some resource.
It is described in detail here:
http://msdn.microsoft.com/en-us/library/ms534710(VS.85).aspx
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.
It does not seem that this attribute has achieved wide author adoption
nor wide application support.
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.
---------------------------
Please reply with any other use cases and prior art you have.
I don't know of any other prior art, except that protocol handling is
already in
http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler
.
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.)
Maybe another similar use case could be a protocol which looked for
commentary or information on a given webpage--e.g.,:
commentary:?url=http://yahoo.com
or
urn:commentary:http://yahoo.com (escaped as needed by URN syntax)
...could find out info about what users had to say about Yahoo.
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
https://addons.mozilla.org/en-US/firefox/addon/5235 )--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.
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.
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.
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).
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.
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.
As far as the existing design of registering handlers, while I think
that should be all right (e.g., as already at
http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler
and also described at
https://developer.mozilla.org/en/Web-based_protocol_handlers ), I think
it'd be nice to be able to see additions to say the navigator object or
<a/> (if not onclick events):
<a href="http://amazon.com..."; defaultProtocol="urn:isbn:..."
onclick="check(event);">Some book</a>
<script>
// We must rely on "onclick" since older browsers wouldn't support a
handler like "onDefaultProtocol" anyways.
// The following demonstrates some potentially useful properties for the
event:
function check (e) {
if (!*navigator.defaultProtocol*) {
if (!confirm("Your browser doesn't support generic protocols;
would you like to be redirected to "+this.href+"?") {
e.preventDefault(); // Here we can prevent the regular 'href'
}
}
else if (!*navigator.defaultProtocol.handlers*) { // or requiring a
key to a specific scheme?
alert("Although your browser supports generic protocols, you do
not have any handlers registered for"+*this.defaultProtocol.scheme*); //
"for urn".
if (!confirm("Would you like to be redirected to the default
URL?") {
e.preventDefault(); // Here we prevent the defaultProtocol
(and href) from proposing a dialog to find a protocol; there could
either be
// special syntax added to allow jumping over the
defaultProtocol to the default 'href', or the JavaScript could simply set
// window.location. The latter would probably be enough.
}
else { window.location.href = this.href; }
}
else {
// Since some handlers might need to make a network connection
to figure out whether they can not only handle the scheme, but also
// the particular content (like for a specialized bookstore
which only recognized certain ISBNs), maybe it should also be possible
to have
// a selection hierarchy order, such that one could activate
checking:
if
(!*navigator.defaultProtocol.handlers.supports*(this.defaultProtocol)) {*
* alert("Unfortunately your registered protocol handlers
cannot support this particular protocol instance.");
e.preventDefault();
}
// 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
alert("We will now open
"+*navigator.defaultProtocol.handlers.selected.name*)+" with
"+*this.defaultProtocol*; // e.g., "...will now open UsedBooks with
urn:isbn:..."
}
}
</script>
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.
Brett
