On 6/4/2010 12:59 PM, Brett Zamir wrote:
On 3/11/2010 10:44 AM, Brett Zamir wrote:
On 3/11/2010 10:31 AM, Ian Hickson wrote:
I would recommend following a pattern somewhat like the Web's initial
development: create a proof of concept, and convince people that
it's what
they want. That's the best way to get a feature adopted. This is
described
in more detail in the FAQ:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
Ok, fair enough. I think I'll try that as a browser extension <snip>
Just as a follow-up, I have now made a Firefox extension which
supports two attributes on <a/>: "uris" and "alternateURIs", whereby
the former takes precedence over "href", and the latter are accessible
only by right-clicking links (though potentially discoverable by
custom styling of such links (automatable by the extension)).
My thought is that sites which have the following goals may be
particularly interested:
1) Those wishing to maintain objectivity and refrain from endorsing
specific sites, e.g., governments, news institutions, scholars, or
sites like Wikipedia. Even for a site's internal links, use of
"alternateURIs" could offer convenience (e.g., Wikipedia would no
doubt wish to continue to use href to refer to its own ISBN page by
default, but could use the "alternateURIs" attribute to allow
right-clicks on the link to activate the URN link which in turn
activates their chosen default handler, e.g., Amazon, Google Books,
etc.). The same could be done for music, etc.
2) giving full user choice as to how to view the data (especially
useful for information of common and particular interest to the site
viewers, e.g., links to the Bible in a religious forum)
3) those wishing to try out new protocols of whatever type (not only
URNs), such as chatting protocols, whether installed via web or
browser extension, as the proposed markup gives them a convenient
fall-back to "href", so they don't have to have dead links for those
whose browsers do not support the protocol.
https://addons.mozilla.org/en-US/firefox/addon/162154/
Just to elaborate a little bit further, one possible future addition
which could further enhance this experience would be to design a
protocol (and corresponding markup-detection mechanism), say "created:"
or "wiki:" which would first check via HEAD request whether the page
were created or not, and then style the link accordingly and possibly
alter the URL to lead directly to the editing or alternatively, it could
make HEAD requests to try out a sequence of URLs, e.g., checking whether
Citizendium had an article, and if not, creating a link to the Wikipedia
article if present. While this could be done potentially via the server
(e.g., this extension for Mediawiki:
http://www.mediawiki.org/wiki/Extension:BADI_Pages_Created_Links ), I
believe allowing client-side markup to do it would facilitate use of
this potential more widely, allowing wikis or open-forums to link with
one another in a way which prevents wasted visits by their users.
Although URNs could also be used (as supported already potentially in
the above extension) to try to find encyclopedic articles (e.g.,
urn:name:pizza), or better yet, through a new protocol which could
suggest intended uses of the information (e.g.,
find:urn:name:pizza?category=order, find:urn:name:pizza?category=define,
etc.) and thereby avoiding hard-coding information, the "created:"
suggestion above could give authors more control than they have now if
they did want to suggest a particular path-way.
Brett
