Charles Roper wrote:
On 20/10/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
Charles Roper wrote:
I need to include the following in a class name (for use in a
microformat):
class="urn:lsid:ubio.org:namebank:530114"
Which microformat? That's a URI and so a more semantic place for
it is in <a href="urn:..."> or maybe <link href="urn:">.
It's actually a URN, a subset of URI which does not imply
availability of the identified resource.
Yes, I know that.
Doesn't this make it inappropriate for an href in the context of a
web page?
No. The attributes: href, cite, data, src, longdesc, etc. are defined
to contain URIs, not just URLs. It is not unprecedented to use a URN in
such an attribute.
e.g. <blockquote cite="urn:isbn:0-534-37131-0">
It would even make sense to use that same URI in
<a href="urn:isbn:0-534-37131-0">Standard C++ with Object-Oriented
Programming</a>
Unfortunately, the practical problem is that browsers generally don't do
anything useful with them, though there is nothing to prevent a browser
from loading the user's preferred online book store (e.g. Amazon.com,
Barnes and Noble, etc.) with more information about the book. Google
did a similar thing with it's AutoLink feature, which recognises plain
text ISBNs in the source and links them to Amazon.
I completely see where you're coming from, though. If it
were a URL then that would be more appropriate for an href surely?
Where does it say in the spec that an href attribute has to point to to
a network-retrievable resource? It explicitly allows URIs, including
both URLs and URNs.
Getting more specific, it's actually an LSID for a microformat that
is still in development. More on LSIDs here:
http://lsid.sourceforge.net/#whatislsid
For future reference, when talking about a microformat, it's useful if
you actually link to something about that microformat, so it's easier to
find what you're talking about. I assume it's the species format that I
found, since it mentions LSIDs in this page.
http://microformats.org/wiki/species-brainstorming
Having said all this, LSIDs can be made to behave like URLs via a
Firefox addin:
http://lsid.biopathways.org/lsid_browser/lsid_browser_1_0_0.html
So perhaps sticking the LSID in the href might be useful after all.
An existing implementation is one of the strongest argument for doing
that way.
You also need to consider that it is much easier for an external 3rd
party plugin to do something with a URI when it's activated (by
registering the URI scheme with the system) than it is to do something
with the class attribute.
There's even a way being developed for scripts in web pages to register
protocol handlers.
http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers
Say, for example, you visit a site that provides some service related to
species, the site could register to handle urn:lsid: URIs, such that
when the user clicks an LSID link, they're taken to that website for
whatever it is they want to do. Amazon.com and other book stores could
do exactly the same thing with urn:isbn: URIs.
Keep in mind that the class attribute is *hidden* metadata, which is
somewhat against the philosophy of microformats. At least with a link,
it's much more visible and easier for the user to access (without
viewing source) and then do something with it.
However, providing a *direct* link to the resource described by the
LSID isn't the intended aim of the microformat; the LSID is in there
as metadata that describe a resource, while the normal hyperlink, if
there is one, probably points to something else entirely.
What's wrong with providing 2 links? One to the LSID, another to the
related information.
--
Lachlan Hunt
http://lachy.id.au/
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
