Print

Print


Hi again, more below on resolving links....

>  Just a point of clarification. Everything which has been
>  discussed concerning href vs. entityref is equally applicable
>  for SGML- and XML-encoded finding aids.

True; Point taken...the point I meant (rather than what I said :) is rather
that using the HREF form of linking instead of ENTITYREF is simply easier
to resolve into HTML for the common/current browser to view, since it saves
a step, and thus opens up your choices for server-side EAD->HTML
translation programs from the delux/sophisticated (DynaWeb) to the
cheap/simpler (Isite/etc). It seems a good thing to have the choice to do
either or both as needed. Perhaps when there is a plethora of cheap, easy
to use, XML client-side display options which can resolve entityrefs, then
it will not matter so much, but for now it's a practical benefit to have
both/either available.

>  I have seen this sort of thing before. You have discovered
>  quite independently that the notations used in entity declarations
>  really do have a use, and you are trying to mimic this functionality
>  through some thoroughly local interpretation of the role attribute.
>  Yes, your solution will work for you, but it *is* a local interpre-
>  tation or redefinition of role (at least in my opinion).

Is this a re-definition of role? The *values* I was assigning to ROLE
(thumbnail/hi-res) are certainly local (although I stole the idea from
other OAC finding aids :), but the *use* of role for this seems appropriate
to qualify the linking element. Michael suggests using the SHOW attribute
instead perhaps, which would also work. Perhaps the ACTUATE attribute could
be used instead; or BEHAVIOR. In any case, the idea is just that HREF is
not necessarily a bad attribute to have, because one can combine it with
other attributes of the linking element to clarify the inherent confusion
that Alvin pointed out (what is the nature of the link, and how to resolve
it); so the HREF+other attributes can be a useful combo which are resolved
easily without server-side parsing programs that have to look at filenames,
etc.

>
>  More discussions, heated arguments, eagerly welcomed.

Yes, more! I'm interested too, because specifically the MOAC project (and
museum use of EAD) most often will include links because quite often images
and other multimedia are included in museum finding aids; and it would of
course be best to have agreement and follow form when implementing these
links as well as have options for implementation which allowed for a wide
range of choice in applications.....(speaking of which; Michael have you or
anyone on the list used the Apache web server's XML features to serve EAD?
Does it enable searching - or just EAD-HTML translation?)




Richard Rinehart
----------------
Information Systems Manager & Education Technology Specialist
Berkeley Art Museum/Pacific Film Archive
@ University of California
http://www.bampfa.berkeley.edu/
----------------
& President, Museum Computer Network, http://www.mcn.edu/