refdb-devel — List for RefDB developers

[Refdb-devel] Anonymous CVS checkout

[Michael S. <sm...@xm...>]

Bruce,

Are you able to check out code from Sourceforge via anonymous CVS?

You should be able to get all the RefDB source by doing this to login:

  cvs -d:pserver:ano...@cv...:/cvsroot/refdb login

(just hit Enter at the password prompt)

Then make a "refdb" directory (doesn't actually matter what you name
it), then cd into it and do this:

  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/refdb co .

That'll get you everything module (currently, "refdb", "perlmod", and
"elisp". If you just a particular module, you can do this:

  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/refdb co elisp

If that works for you, then I won't bother attaching updated versions or
diffs to e-mail -- I'll just send an "new version checked in, update
your sandbox" note to the list.

  --Mike

[Refdb-devel] Please test with latest CVS source (v1.2)

[Michael S. <sm...@xm...>]

Hi Markus,

You wrote:

[...]

> BTW I've tested 1.5 on the weekend real quick. It was entirely broke
> for me but I didn't have the time to investigate this yet. I'll be
> back with fixes or at least a complete problem description asap.

Please try with the latest CVS source (refdb-mode.el 1.2).

I've tested that on Cygwin and Debian Linux with both Emacs 21 and 20,
and it seems to be working fine.

There was one minor bug in the output-buffer-choose-mode code in v1.1,
but I've since checked in a fix for it.

Anyway, if you try with the CVS source and it's still broke for you,
definitely please let me know.

  --Mike

[Refdb-devel] minor refdbd.h.in bug

[Michael S. <sm...@xm...>]

Markus,

Ran into a minor snag when trying to build from the latest CVS source.
Patch (such as it is) below.

--- refdbd.h.in.orig	2003-12-16 14:00:18.652244700 +0900
+++ refdbd.h.in	2003-12-16 14:01:45.845446500 +0900
@@ -122,7 +122,7 @@
 int run_keyword_scan(struct CLIENT_REQUEST* ptr_clrequest, Lilid* ptr_sentinel, int mode);
 int addnote(struct CLIENT_REQUEST* ptr_clrequest, char* set_owner, struct ADDRESULT* ptr_addresult, int replace_note, Lilid* ptr_sentinel);
 int deletenote(struct CLIENT_REQUEST* ptr_clrequest, struct DELRESULT* ptr_delresult);
-unsigned long long getnote(struct CLIENT_REQUEST* ptr_clrequest, struct bibinfo *ptr_biblio_info, int ref_format, char *cgi_url);
+unsigned long long getnote(struct CLIENT_REQUEST* ptr_clrequest, struct bibinfo *ptr_biblio_info, int ref_format, int n_privatelist, char *cgi_url);
 int addlink(struct CLIENT_REQUEST* ptr_clrequest, char* set_owner, struct ADDRESULT* ptr_addresult, int n_remove);
 struct CLIENT_REQUEST* new_client_request(void);
 struct CLIENT_REQUEST* dup_client_request(struct CLIENT_REQUEST* ptr_clrequest);

[Refdb-devel] Please file refdb-mode bug reports & feature requests at Sourceforge

[Markus H. <mar...@mh...>]

Michael Smith writes:
 > Please use the project Tracker interface and Sourceforge to file any
 > open or new feature request or bug report for refdb-mode.
 > 
 >   http://sourceforge.net/tracker/?group_id=26091
 > 
 > I've just been going through my e-mail inbox to see if there's anything
 > we've discussed that I haven't fixed yet or added to my todo list, but
 > I've probably missed some things, and probably will miss some things in
 > the future if they're only sent via e-mail. Having things logged in the
 > tracker will prevent them from falling between the cracks.
 > 

Ok, will do.

 > Markus, if you have time and can add a new "Emacs refdb-mode" category
 > to the Bugs and Feature Requests trackers, and set it up so that items
 > submitted in the category automatically get assigned to me, I'd
 > appreciate it.
 > 

This should work now as requested. Drop me a line if it doesn't work
as expected.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] Build problems + patch

[Markus H. <mar...@mh...>]

Michael Smith writes:
 > Markus,
 > 
 > I ran into some build errors while trying to build refdbd from my
 > sandbox. A patch is included below.
 > 

Thanks for the patch. I haven't visited the Cygwin-specific code in a
while, and this shows.

 > Also, the current build doesn't seem to make refdbd.h from refdbd.h.in.
 > 

This is because I forgot to check in the modified Makefile.am - sorry
about that. I've checked it in just a minute ago.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] Please file refdb-mode bug reports & feature requests at Sourceforge

[Michael S. <sm...@xm...>]

Please use the project Tracker interface and Sourceforge to file any
open or new feature request or bug report for refdb-mode.

  http://sourceforge.net/tracker/?group_id=26091

I've just been going through my e-mail inbox to see if there's anything
we've discussed that I haven't fixed yet or added to my todo list, but
I've probably missed some things, and probably will miss some things in
the future if they're only sent via e-mail. Having things logged in the
tracker will prevent them from falling between the cracks.

Markus, if you have time and can add a new "Emacs refdb-mode" category
to the Bugs and Feature Requests trackers, and set it up so that items
submitted in the category automatically get assigned to me, I'd
appreciate it.

  --Mike

[Refdb-devel] Fwd: [relaxng-user] ANN: Relax NG Compact Syntax validator in C

[Bruce D'A. <bd...@fa...>]

A new rng validator at:

	  http://davidashen.net/rnv.html

Bruce

Begin forwarded message:

> From: Sebastian Rahtz <seb...@co...>
> Date: December 15, 2003 5:55:22 PM EST
> To: David Tolpin <dv...@da...>
> Cc: rel...@re...
> Subject: Re: [relaxng-user] ANN: Relax NG Compact Syntax validator in C
>
> David Tolpin wrote:
>
>> I've posted the first release of RNV, a Relax NG (Compact Syntax) 
>> validator (written in C),
>>
> I'm impressed! It ate all my test files at first go, at lightning 
> speed, and gave a good error report
> when I introduced a mistake.
>
> 65000 lines of the TEI Guidelines in 1.9 seconds, 5 times faster than 
> jing. Datatype checking
> would be good one day.....
>
> Thanks for this!
>
> Sebastian Rahtz

[Refdb-devel] Build problems + patch

[Michael S. <sm...@xm...>]

Markus,

I ran into some build errors while trying to build refdbd from my
sandbox. A patch is included below.

Also, the current build doesn't seem to make refdbd.h from refdbd.h.in.

  --Mike

--- refdbd.ORIG.c	2003-12-13 15:01:28.247848700 +0900
+++ refdbd.c	2003-12-13 16:57:38.867988900 +0900
@@ -660,7 +660,7 @@
 		    LOG_PRINT(LOG_WARNING, "incomplete message - confserv aborted");
 		  }
 		  else {
-		    confserv(fifo_buffer, clrequest.server_ip);
+		    confserv(fifo_buffer, ptr_clrequest->server_ip);
 		  }
 		}
 		else {
@@ -668,7 +668,7 @@
 		}
 	      }
 	      else {
-		confserv(fifo_buffer, clrequest.server_ip);
+		confserv(fifo_buffer, ptr_clrequest->server_ip);
 	      }
 	      close(fd_fifo);
 	      unlink(the_fifo);
@@ -685,7 +685,7 @@
 		  LOG_PRINT(LOG_WARNING, "incomplete message - confserv aborted");
 		}
 		else {
-		  confserv(fifo_buffer, clrequest.server_ip);
+		  confserv(fifo_buffer, ptr_clrequest->server_ip);
 		}
 	      }
 	      else {
@@ -693,7 +693,7 @@
 	      }
 	    }
 	    else {
-	      confserv(fifo_buffer, clrequest.server_ip);
+	      confserv(fifo_buffer, ptr_clrequest->server_ip);
 	    }
 	    close(fd_fifo);
 	    unlink(the_fifo);

[Refdb-devel] Emacs minibuffer behavior

[Michael S. <sm...@xm...>]

Markus Hoenicka <mar...@mh...> writes:

[...]

> One minor thing I've noted though is that in some queries the
> *refdbc-output* buffer does not pop up. Instead you see the result in
> the minibuffer, although *refdbc-output* is updated properly. Is Emacs
> doing this by design?

I've now made a change to cause any refdbc output that's longer than one
line to force the refdbc-output buffer to be displayed (instead of being
shown in the minibuffer). It'll be included in the next checkin I make
(within the next couple of days).

  --Mike

Re: [Refdb-devel] refdbc -C addref & stdin

[Michael S. <sm...@xm...>]

Hi Markus,

You wrote:

> Michael Smith writes:
>  > Tonight was the first time I actually tried adding data to the db, and
>  > environment I was trying it on is a Cygwin install. Haven't tried it on
>  > my Linux install yet.
>  > 
>  > Anyway, got it working on Cygwin by hacking the refdbc source. So the
>  > both the command line and Emacs interaction are working as expected for
>  > me now.
>  > 
> 
> The -f stdin switch should do the trick without source hacks.

OK -- I have this working as expected now after applying the patch you
send and building from sandbox source. Thanks

>  > > If I try to do it from the menu though (this with an risx file), I get 
>  > > this:
>  > > 
>  > > Could not set terminal attributes
>  > 
>  > That's a warning coming from refdbc. I'm not sure what it indicates, but
>  > I don't think it causes any problems.
>  > 
> 
> It indicates that refdbc is asking for a password which is bound to
> fail. Please set the password in .refdbcrc.

Thanks -- that works also for me now that I've set that password in the
config file. 

>  > > data read error. Stop.
>  > 
>  > damn. Well. that one is also coming from refdbc too, and I think it's a
>  > fatal error. If you're able to succesfully add data via the command line
>  > but not from within Emacs, then either I'm not using the Emacs
>  > shell-command-on-region function correctly, or there's something wrong
>  > with the way your Emacs is interacting with the shell.
>  > 
> 
> It works fine over here, but I haven't tested this on Cygwin yet. Do
> you use Cygwin's Emacs or NT Emacs?

I'm actually testing both on Cygwin both with Cygwin Emacs 21.2 and
X-Windows and with NT Emacs 21.3. Using my sandbox binaries and with the
password set in my refdbcrc file, I'm not seeing any unexpected behavior
now (as long as I make sure to select the leading newline when sending
data to refdbc).

  --Mike

Re: [Refdb-devel] XHTML output type?

[Michael S. <sm...@xm...>]

Hi Markus,

You wrote:

> Michael Smith writes:
>  > In an earlier message, Markus mentioned an 'xhtml' output type. But
>  > unless there's some magic that I'm missing somewhere, there isn't
>  > actually any XHTML output option, right?
>  > 
>  >   --Mike
> 
> getref -t xhtml should return xhtml output.

Indeed it does. Testing with the binaries built from the latest source,
I see it works. I've added it back into the input-type menu.

  --Mike

Re: [Refdb-devel] refdbc -C addref & stdin

[Michael S. <sm...@xm...>]

Hi Markus,

You wrote:

> Michael Smith writes:
>  > Will it break behavior on other platforms if I just include the -f stdin
>  > option by default in the set of args that Emacs passes to
>  > refdbc -C addref ? That is, is -f stdin just ignored on platforms that
>  > can already auto detect data on stdin?
>  > 
> 
> It is safe to use this switch on all platforms. The switch isn't
> actually ignored on the other platforms but it sets a variable to 1
> which has the value 1 anyway if data are available on stdin.

OK. I've added it as the default value for variable that sets additional
options for the commands that accept stdin (addref & updateref, for now).

>  > Anyway, when I actually try it on Cygwin, it doesn't seem to work -
>  > 
>  >   $ refdbc -d foo -C addref -f stdin < /tmp/data/alltypes.ris 
>  >   Could not set terminal attributes
>  >   0 dataset(s) added, 0 skipped, 0 failed
>  >   0 dataset(s) sent.
>  > 
> 
> I'm afraid this is my fault. I've just checked that for reasons
> entirely unclear to me addref does not yet support the -f stdin
> switch. It will fail on Cygwin no matter how hard you'll try. The
> appended patch fixes the problem. It is against a current CVS version
> so expect some hunks to fail if you try to patch 0.9.3.

Thanks -- I applied this patch to source in my CVS sandbox and built
from there. (Had a couple of problems building -- will send a separate
message about those.) So, I've now set up to test with binaries built
from the latest source.

  --Mike

Re: [Refdb-devel] refdbc -C addref & stdin

[Markus H. <mar...@mh...>]

Michael Smith writes:
 > I've been able to reproduce this error just by selecting/marking a
 > reference but not the blank line/newline that precedes it.
 > 
 > I saw a note in the docs that says all RIS files must begin with a
 > newline; seems like that's also true of any RIS data sent to refdbc.
 > 
 > Markus, would it be possible to make refdbc liberal in this regard -- to
 > process data for stdin even if it doesn't begin with a newline?
 > 
 > Perhaps it could just quietly and automatically add a newline to the
 > beginning of any data it receives. I know that would mean that if the
 > user had actually sent data that began with a newline, there'd be an
 > extra one. Would that break anything? If so, maybe refdbc could check to
 > see if there was a newline, and only add one if there isn't one already.
 > 

This indeed explains the behaviour. There is no problem with adding
newlines to the beginning of a file/buffer. Any excess newlines will
simply be skipped. I'll figure out a patch.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] refdbc -C addref & stdin

[Michael S. <sm...@xm...>]

Markus Hoenicka <mar...@mh...> writes:

> Bruce D'Arcus writes:
>  > 
>  > I'm not getting the first error anymore, but I am still getting the 
>  > second (the "data read" error).
>  > 
> 
> This essentially means that refdbc can't read from stdin. There's a
> couple of things to check:
> 
> 1) make sure that the commands run by refdb-menu do work on the
>    command line. If not, it's probably a platform issue.
> 
> 2) try adding the -f stdin switch to the appropriate code in
>    refdb-menu.el
> 
> 3) replace the refdbc call with a different program (maybe 'grep
>    ".*"') to see whether the shell within Emacs correctly pipes the
>    contents of the buffer to stdin of the called program.

I've been able to reproduce this error just by selecting/marking a
reference but not the blank line/newline that precedes it.

I saw a note in the docs that says all RIS files must begin with a
newline; seems like that's also true of any RIS data sent to refdbc.

Markus, would it be possible to make refdbc liberal in this regard -- to
process data for stdin even if it doesn't begin with a newline?

Perhaps it could just quietly and automatically add a newline to the
beginning of any data it receives. I know that would mean that if the
user had actually sent data that began with a newline, there'd be an
extra one. Would that break anything? If so, maybe refdbc could check to
see if there was a newline, and only add one if there isn't one already.

  --Mike

Re: [Refdb-devel] Updated Emacs package, syntax highlighting, new name

[Markus H. <mar...@mh...>]

Markus Hoenicka writes:
 > Ah, I see. If I find some time tonight I'll have a look at that
 > marvellous w3 mode. If there's a trick to display a buffer containing
 > a HTML document with that mode, we might consider using the HTML
 > output as a pretty-printed version instead. But I've got no idea
 > whether this is going to work.
 > 

This apparently works. It uses the configured stylesheet and looks
pretty cool on an X display, see attached image.

regards,
Markus

Re: [Refdb-devel] Updated Emacs package, syntax highlighting, new name

[Michael S. <sm...@xm...>]

Hi Markus,

You wrote:

> Michael Smith writes:
>  > It is now, by setting the refdb-output-type variable. What I meant was,
>  > the intial value for it in the defvar in the code is 'scrn. I was
>  > wondering if it should maybe be 'ris instead. Users could still
>  > configure it to have any initial value they want. It'd just be that, if
>  > they didn't configure it, it would default to 'ris instead of defaulting
>  > to 'scrn.
>  > 
> 
> Ah, I see. If I find some time tonight I'll have a look at that
> marvellous w3 mode. If there's a trick to display a buffer containing
> a HTML document with that mode, we might consider using the HTML
> output as a pretty-printed version instead. But I've got no idea
> whether this is going to work.

Well, we're not actually limited to using w3 mode. The code can write
the HTML output to a temp file, and then just have Emacs call
browse-url on that, which will in turn call whatever browser the user
has selected as his or her preferred browser.

I think users would probably prefer that rather than having it
hard-coded to display in w3 mode. The code wouldn't need to know or care
what their preferred browser is -- for users who had their preferred
browser set to w3, it'd send it to w3. Otherwise, whatever else they had
selected. I have my own Emacs set up to call Mozilla.

> BTW I've tested 1.5 on the weekend real quick. It was entirely broke
> for me but I didn't have the time to investigate this yet. I'll be
> back with fixes or at least a complete problem description asap.

OK -- thanks. Note that when I changed the name to "refdb-mode", I
changed every single variable name as well. So if you still have any
related config variables in your .emacs that you haven't updated to the
new names yet, that may be part of the problem.

  --Mike

Re: [Refdb-devel] Updated Emacs package, syntax highlighting, new name

[Markus H. <mar...@mh...>]

Michael Smith writes:
 > It is now, by setting the refdb-output-type variable. What I meant was,
 > the intial value for it in the defvar in the code is 'scrn. I was
 > wondering if it should maybe be 'ris instead. Users could still
 > configure it to have any initial value they want. It'd just be that, if
 > they didn't configure it, it would default to 'ris instead of defaulting
 > to 'scrn.
 > 

Ah, I see. If I find some time tonight I'll have a look at that
marvellous w3 mode. If there's a trick to display a buffer containing
a HTML document with that mode, we might consider using the HTML
output as a pretty-printed version instead. But I've got no idea
whether this is going to work.

BTW I've tested 1.5 on the weekend real quick. It was entirely broke
for me but I didn't have the time to investigate this yet. I'll be
back with fixes or at least a complete problem description asap.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] refdb db in menu?

[Markus H. <mar...@mh...>]

Michael Smith writes:
 > Ah, OK. I guess I can then hard-code it into the Emacs code. You say it
 > changes once in a while, and I remember that it's 'refdb1' for v0.9.3.
 > Does that mean you alternate it between those two values, and so if I
 > have the Emacs code filter out both "refdb" and "refdb1", it will handle
 > things OK if/when you need to change the name again?
 > 

This should do the trick. So far I didn't find any reason to use
something else but refdb or refdb1.

 > OK. But, along with the blacklist, should I just have it hard-coded to
 > always ignore the following, even if they're not included in the
 > blacklist? If not, there's a risk of users trying to add RefDB data to
 > these databases.
 > 
 >   refdb refdb1 mysql template0 template1
 > 

This is the pitch dark black list, so to speak. In no case a reference
database should have one of these names.

 > Yes, I think it should be on your todo list. How much of a priority it
 > should be relative to other things you have on there, I can't say.
 > 

Ok. I'll put it on my list then. I'll make that user-configurable to
save time for those who know what they're doing.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] Updated Emacs package, syntax highlighting, new name

[Michael S. <sm...@xm...>]

Hi Markus,

You wrote:

> Michael Smith writes:
>  > Actually, I wonder whether the default in Emacs should be something
>  > other than the "screen" output -- maybe RIS? We'd be distributing the
>  > refdb-mode.el package along with the ris.el package anyway, and to my
>  > eyes at least, that package give a nice, readable, syntax-highlighted
>  > view of the data.
>  > 
> 
> As always, there won't be a real consensus on this. Could this be made
> user-configurable?

It is now, by setting the refdb-output-type variable. What I meant was,
the intial value for it in the defvar in the code is 'scrn. I was
wondering if it should maybe be 'ris instead. Users could still
configure it to have any initial value they want. It'd just be that, if
they didn't configure it, it would default to 'ris instead of defaulting
to 'scrn.

  --Mike

Re: [Refdb-devel] refdb db in menu?

[Michael S. <sm...@xm...>]

Hi Markus,

You wrote:

> Michael Smith writes:
>  > hmm, I realize now that naming the base db "refdb" is arbitrary. I guess
>  > a user could choose during install to call the base database "mybasedb"
>  > or whatever, and then could create another database called "refdb", and
>  > have references added to that.
>  > 
> 
> No, the name is not arbitrary. It is hard-coded in the main header
> file. The name changes once in a while if I change the database schema
> and want to allow users to run parallel installations of RefDB using
> the old and the new schemas at the same time.

Ah, OK. I guess I can then hard-code it into the Emacs code. You say it
changes once in a while, and I remember that it's 'refdb1' for v0.9.3.
Does that mean you alternate it between those two values, and so if I
have the Emacs code filter out both "refdb" and "refdb1", it will handle
things OK if/when you need to change the name again?

>  > Or to make it more configurable, we could add refdb-listdb-ignore-list
>  > variable, again with default value "refdb", but make it a list. Users
>  > could put multiple names into it that way, and then wouldn't need to
>  > mess around with trying to figure out how to construct a regex and
>  > express it in whatever syntax their backend database supported.
>  > 
>  > And that way, we could also include the built-in database names for the
>  > backends -- i.e. Postgres's "template0" and "template1" databases, and
>  > whatever the names are of the built-in databases that MySQL sets up.
>  > 
> 
> The latter is "mysql" (who would have guessed that?).

Heh -- I should have guessed, I guess :)

>  > How does that sound?
>  > 
> 
> I think it may be useful in quite a couple of cases, so I'd suggest to
> add such a list. This black list together with the regexp that allows
> to define a white list should be sufficient to pick the right
> databases.

OK. But, along with the blacklist, should I just have it hard-coded to
always ignore the following, even if they're not included in the
blacklist? If not, there's a risk of users trying to add RefDB data to
these databases.

  refdb refdb1 mysql template0 template1

>  > Now that I write all that, though, I wonder whether that logic might not
>  > be better handled on the RefDB side -- so that refdbd -C listdb wouldn't
>  > return the name of the base RefDB database, whatever its name, or of the
>  > built-in backend database names.
>  > 
> 
> I could do this of course, but it is still a half-assed solution as it
> does not solve the problem of non-RefDB databases served by the same
> database engine. A real solution would require refdbd to test each
> database returned by listdb whether or not it is a RefDB database,
> e.g. by running a query that retrieves values of all fields listed by
> their names. This would also filter out databases that the user has no
> permission to access anyway. Should I put this on my todo list?

Yes, I think it should be on your todo list. How much of a priority it
should be relative to other things you have on there, I can't say.

  --Mike

[Refdb-devel] mods and hierarchical sujbects

[Bruce D'A. <bd...@fa...>]

Turns out the MARC/MODS subject structure is more flexible/complex than 
I'd realized.  Here's a record I just coded:

<?xml version="1.0" encoding="utf-8"?>
<modsCollection xmlns="http://www.loc.gov/mods/v3">
   <mods ID="Tilly2000a">
     <name type="personal">
       <namePart type="given">Charles</namePart>
       <namePart type="family">Tilly</namePart>
       <role>
         <roleTerm type="text">reviewer</roleTerm>
       </role>
     </name>
     <titleInfo>
       <title>Review of Moral Economy and Popular Protest</title>
     </titleInfo>
     <subject>
       <topic>riots</topic>
       <name type="personal">
	<namePart type="given">Edward</namePart>
	<namePart type="given">P.</namePart>
	<namePart type="family">Thompson</namePart>
       </name>
       <titleInfo>
	<title>Moral Economy and Popular Protest</title>
	<subTitle>Crowds, Conflict and Authority</subTitle>
       </titleInfo>
       <name type="personal">
	<namePart type="given">Adrian</namePart>
	<namePart type="family">Randall</namePart>
	<role>
	  <roleTerm type="text">editor</roleTerm>
	</role>
       </name>
       <name type="personal">
	<namePart type="given">Andrew</namePart>
	<namePart type="family">Charlesworth</namePart>
	<role>
	  <roleTerm type="text">editor</roleTerm>
	</role>
       </name>
     </subject>
     <genre>review</genre>
     <relatedItem type="host">
       <titleInfo>
	<title>Journal of Interdisciplinary History</title>
       </titleInfo>
       <typeOfResource>text</typeOfResource>
       <originInfo>
	<dateIssued>2000</dateIssued>
       	<issuance>continuing</issuance>
       </originInfo>
       <genre>periodical</genre>
       <part>
         <detail type="volume"><number>31</number></detail>
         <detail type="issue"><number>2</number></detail>
	<extent unit="page">
           <start>259</start>
           <end>260</end>
	</extent>
       </part>
     </relatedItem>
     <recordInfo>
       <recordCreationDate 
encoding="w3cdtf">2003-12-11</recordCreationDate>
       <recordIdentifier source="citekey">Tilly2000a</recordIdentifier>
     </recordInfo>
   </mods>
</modsCollection>

Re: [Refdb-devel] Updated Emacs package, syntax highlighting, new name

[Bruce D'A. <bd...@fa...>]

On Dec 13, 2003, at 4:05 PM, Markus Hoenicka wrote:

>> But that is all said without having much insight in the use cases for
>> the various output types for the data. I guess I can see the 
>> advantages
>> of the 'screen' format when you're looking at the data in a shell, but
>> what's the value of viewing it that way in Emacs? Just the brevity?
>
> The screen output was indeed designed for viewing the results in an
> xterm.

Maybe you could add some code to ris.el to allow syntax highlighting of 
the screen output?

Bruce

Re: [Refdb-devel] Updated Emacs package, syntax highlighting, new name

[Markus H. <mar...@mh...>]

Michael Smith writes:
 > Actually, I wonder whether the default in Emacs should be something
 > other than the "screen" output -- maybe RIS? We'd be distributing the
 > refdb-mode.el package along with the ris.el package anyway, and to my
 > eyes at least, that package give a nice, readable, syntax-highlighted
 > view of the data.
 > 

As always, there won't be a real consensus on this. Could this be made
user-configurable?

 > But that is all said without having much insight in the use cases for
 > the various output types for the data. I guess I can see the advantages
 > of the 'screen' format when you're looking at the data in a shell, but
 > what's the value of viewing it that way in Emacs? Just the brevity?
 > 

The screen output was indeed designed for viewing the results in an
xterm.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] refdb db in menu?

[Markus H. <mar...@mh...>]

Michael Smith writes:
 > hmm, I realize now that naming the base db "refdb" is arbitrary. I guess
 > a user could choose during install to call the base database "mybasedb"
 > or whatever, and then could create another database called "refdb", and
 > have references added to that.
 > 

No, the name is not arbitrary. It is hard-coded in the main header
file. The name changes once in a while if I change the database schema
and want to allow users to run parallel installations of RefDB using
the old and the new schemas at the same time.

 > Or to make it more configurable, we could add refdb-listdb-ignore-list
 > variable, again with default value "refdb", but make it a list. Users
 > could put multiple names into it that way, and then wouldn't need to
 > mess around with trying to figure out how to construct a regex and
 > express it in whatever syntax their backend database supported.
 > 
 > And that way, we could also include the built-in database names for the
 > backends -- i.e. Postgres's "template0" and "template1" databases, and
 > whatever the names are of the built-in databases that MySQL sets up.
 > 

The latter is "mysql" (who would have guessed that?).

 > How does that sound?
 > 

I think it may be useful in quite a couple of cases, so I'd suggest to
add such a list. This black list together with the regexp that allows
to define a white list should be sufficient to pick the right
databases.

 > Now that I write all that, though, I wonder whether that logic might not
 > be better handled on the RefDB side -- so that refdbd -C listdb wouldn't
 > return the name of the base RefDB database, whatever its name, or of the
 > built-in backend database names.
 > 

I could do this of course, but it is still a half-assed solution as it
does not solve the problem of non-RefDB databases served by the same
database engine. A real solution would require refdbd to test each
database returned by listdb whether or not it is a RefDB database,
e.g. by running a query that retrieves values of all fields listed by
their names. This would also filter out databases that the user has no
permission to access anyway. Should I put this on my todo list?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] new-document and doc-processing menu behavior

[Markus H. <mar...@mh...>]

Bruce D'Arcus writes:
 > Once support for the new biblioref element is added, the distinction 
 > between the two will evaporate; right?
 > 

Basically yes. There's just the issue of first vs. subsequent
citations of the same reference that I'll have to deal with in a
different way. But Peter claims this is doable in XSLT, so this must
work as well in DSSSL.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de