lynx-dev Lynx Support for the bibp: scheme (Bibliographic Protocol)

[Rob Cameron]

I would like to volunteer to add support for the bibp: scheme to lynx,
according to the document "Bibliographic Protocol Level 1:
Link Resolution and Metapage Retrieval" currently an internet-draft at
http://search.ietf.org/internet-drafts/draft-cameron-tatu-bibp-01.txt
and soon to be published as an RFC.

Bibliographic protocol is supported for most major web browsers
(Netscape 3 through 6, IE 4+ and Opera 4) through a short
JavaScript program (less than 40 lines) that accompanies documents
containing bibp links.   Lynx is the major exception.  

Rather than add JavaScript support to lynx (a daunting task), I would
like lynx to be the first browser with native support for bibp.   

Upon downloading and reviewing the source code for the 2-8-4 version,
I estimate that less than 100 lines of source code are needed.   The
reason that so few lines should be needed is that bibp links simply
translate to http requests on particular bibliographic services. 
The logic of service identification and link translation 
is only about a dozen lines of the JavaScript resolver.  

In essence, bibp support can be a fairly lightweight addition to
lynx and I hope that it can be added in a way that has minimal
impact on the code complexity.

Now, I must admit that bibp is a new development and not a well
established protocol like http, ftp or gopher.   But we think
that bibp has a good future and would certainly welcome discussing
it with members of the lynx-dev.   In essence, bibp could be
considered to provide a specialized version of the URN 
(uniform resource name) concept for items published in organized
serial collections (e.g., books, journals, conference proceedings,
technical reports).   A key difference is that bibp uses a simple
resolution concept that is fully supported by DNS as it exists now,
whereas the URN faces the perhaps insurmountable task of defining,
implementing, and deploying new versions of DNS.   

Philosophically, BibP represents an "open identifier" alternative
for bibliographic reference linking, in marked contrast to the
"closed identifier" model being pursued by major commercial publishers
through the DOI (digital object identifier) initiative.   It is open
in the sense that libraries (and others) can install resolvers that handle
local bibp requests from a domain (e.g., yale.edu) simply by
installing a machine "bibhost" in that domain (bibhost.yale.edu).  
The library resolver will capture bibp links and can provide access
to locally available holdings of journals whether in print or on-line. 
This neatly addresses the "appropriate copy" problem well-known in the
literature on reference linking.  The DOI model is closed in that
identifiers must be ones assigned by publishers (they can't be
worked out by librarians and others with documents in hand), and
they must be resolved through publisher servers.

With that brief introduction, my question is whether our implementation
of bibp support in lynx would be welcomed and, if so, how should
we go about it?   The major changes would be to the getfile
routine in LYGetFile.c, principally adding new logic for a BIBP_URL_TYPE.
But a number of small changes are required in several other files.
For example, no_goto_bibp = !(CAN_ANONYMOUS_GOTO_BIBP); in LYUtils.c
adding BIBP_URL_TYPE to the UrlTypes enum and so on.    

Robert D. Cameron, Ph. D.
Associate Dean of Applied Sciences
Professor of Computing Science
8888 University Drive
Simon Fraser University
Burnaby, B.C., Canada  V5A 1S6
http://www.cs.sfu.ca/~cameron/



; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden