[whatwg] URN or protocol attribute

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100211/75ec9394/attachment-0001.htm>

Received on Wednesday, 10 February 2010 23:10:49 UTC