[gcs-pcs-list] revised latent OpenURL suggestion

[Daniel Chudnov]

This is thorny stuff, and there doesn't seem to be a single good
answer.  Below is a near-rant on why I'm coming down on the side
of rel="openurl".


Eric Hellman wrote, on Wed, Apr 13, 2005 at 05:07:28PM -0400:
> 
> Open issues are
> 1. Which attribute of anchor element to use for marking?
> a. CLASS (my suggestion)
> b. REL (suggested by Alf Eaton, good arguments both ways)
> c. TITLE (suggested by Ross Singer, used? in experiment.)
> It seems everyone else is indifferent.

I like CLASS because everybody knows about it.  I also like CLASS because
this use fits the HTML spec definition "For general purpose processing
by user agents."

I dislike CLASS because its usage, I assume, is overwhelmingly for
support of stylesheets, not for general purpose processing by user agents.
Stylesheet properties cascade; that styles may be applied to a wide range
of elements and their object-ish cascading action means the designation
of a particular class value on an arbitrary element will be handled
similarly to other elements with the same class value.  Also, the domain
of possible elements with the class="openurl|z3988" value is far, far
greater than the single element we want this pattern to work for: <A>.
It therefore seems to me that this will mix up a well-established paradigm
for clean stylesheet design with an odd property pattern that doesn't
quite fit that paradigm.

I also dislike CLASS because we could use a different attribute to solve
this problem without preventing you from using class='z3988' in your
own particular webapps, and without needing the rest of the world to
understand what you mean by that.  That fits the dominant paradigm.

So, -1 on CLASS for me.


I like REL because it's in common use already for "autodiscovery"
applications, and even though this doesn't quite feel like autodiscovery
yet, I think it's a stepping stone to it.  So people who know and
love autodiscovery will feel comfortable with it, and those are the
very people who will hack the early plugins and such that we need to
make this thing scale.

I also like REL because it almost fits the HTML spec definition "describes
the relationship from the current document to the anchor specified by
the href attribute."  I say "almost" because as we all want to use it,
the document containing these "latent" links might itself have multiple
latent links (see citeulike).  So, in a way, we really want a particular
link to describe a relationship between a current _object_ and an anchor.
I doubt this distinction would be lost on many people.

I also like REL because it only applies to A and LINK elements.

I dislike REL because I don't want to have to require profile references.
In the XFN example Alf pointed out they don't seem to say a lot about
how "you have to also reference this profile", although they do mention
profiles.  Mostly they just say "say rel='slept-with' if you slept
with that person etc."  If we can't do this without really _requiring_
the profile piece to be formally stated by most applications using it,
then I'm against REL completely.

Otherwise, +1 on REL.


I like TITLE because it fits the HTML spec, "offers advisory information
about the element for which it is set."  But, that's just advisory 
information, not a formal relationship or class designator.  So, it's
nice if webapps have a little hover-over thing that highlights to
GUI browser users that "this is an OpenURL" or the equivalent for the sightless
in screen readers.  But I don't think that should be the primary place
for our "automated" hacks to reside.

-1 on specifying TITLE as the primary designator for OpenURLs.  
+1 on allowing TITLE as an optional descriptor with the value "OpenURL".

I could live with just not mentioning it at all, although there seems
to be more value in having an optional recommendation than not.


> 2. Should embedded 0.1 links be supported? (Decent activating agents 
> will, of course have to support making both 0.1 and 1.0 links out of 
> the embedded ones) My view is NO, but Ross reasonably raises the 
> question. Perhaps his points can be addressed by requiring a very 
> simple form of OpenURL 1.0?

I think we should avoid this issue completely.  If publishers want
to produce working openurl links, they should stick to the standard.
Resolvers should be liberal in what they accept.  We shouldn't force
the issue.  Hacks/plugins which use the spec we're proposing should
only have to look for one thing in one place (or, rather, "one pattern,
that might occur multiple times in a single document") and not operate
differently according, depending.  That'll keep the plugin space simple,
and potentially fertiler.  Yes, I said fertiler.  More fertile.


> 3. Is there need for TYPE or version?
> I don't understand what the motivation for TYPE is. Versioning seems 
> to be addressed by OpenURL 1.0.

I dislike using TYPE because we're not in a position to add value
to descriptions of content type.  We don't know what content type
people will end up with, that's why we want them to choose from a list
of services themselves.


The remaining open issue is the recommended value of the attribute,
which is separate from which attribute it should be set on.

I like "z3988" because that's what it is, and people can (potentially)
google it and get exactly what we mean.  Right now, they'd get a
mushroom slicer first, and Eric's document second.  If this took
off, goodness-be-with the mushroom slicer vendors.

I dislike "z3988" because people won't remember it.  If they do
remember it, they'll mistype it.  Even if they mistype it, they
might not notice it because 9s and 8s look somewhat familiar.

Overall, -1 on "z3988", but I could live with it if there were a
better argument than these.

I like "openurl" because that's what it is.  People can google it
and get exactly what we mean.  I also like it because people can
remember it and type it correctly.

I dislike "openurl" because people might also use it as a tag name on
rel attributes for folksonomaniacal reasons, which blurs the hackability 
distinction.  Hmm, but actually this concern also applies to "z3988"
or any other possible value in rel.  What's the worst case?

  Somebody uses the tag "openurl" on a flickr post (yeah, right)
  or a blog or linkblog entry.  A greasemonkey userscript sees the
  "openurl" value on the rel attribute and activates a button and stuff.
  User clicks button and gets a resolver error screen.  
  
Come to think of it, that's why we originally tried "rel='alternate'"
_and_ "title='OpenURL'"... the one reinforced the other.  But, nobody's
voting for that combination.

Hmm... I can probably live with that, because among the people who might
actually be tagging flickr or linkblog posts with the tag "openurl" most
should be smart enough to figure out why they reached an error screen,
or at least smart enough to shrug it off and hit their back button.
Not a problem for the other 300000+ other possible tags.

+1 on [whatever]="openurl".

I'm indifferent on also using rel="alternate", as in the suggested
example rel="alternate z3988" or rel="alternate 


...all of which leaves me with voting for rel="openurl" and an optional
suggestion of title='OpenURL'.


One thing we haven't addressed is whether there should be a recommended
behavior for what actually happens when "latent" openurls are "activated".
My gut says "don't specify anything", but it's worth raising explicitly.

I told you it would be a near-rant.

  -Dan


-- 
Daniel Chudnov
Yale Center for Medical Informatics
(203) 737-5789