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