Brett Zamir wrote:

Internet Explorer has an attribute on anchor elements for URNs:

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

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.

== 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)

== 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:

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.

=== 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:

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.


Please reply with any other use cases and prior art you have.

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.

Reply via email to