LISTSERV mailing list manager LISTSERV 16.5

Help for TEI-L Archives


TEI-L Archives

TEI-L Archives


TEI-L@LISTSERV.BROWN.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEI-L Home

TEI-L Home

TEI-L  February 2004

TEI-L February 2004

Subject:

<publicationStmt>: time to shore up loose ends?

From:

Syd Bauman <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Thu, 26 Feb 2004 21:06:57 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (655 lines)

                     <publicationStmt>:
                     where it is,
                     how it got here, and
                     where it should go


<publicationStmt>, present: the current state
------------------ -------- --- ------- -----
Kevin is correct, 5.2.4 of P4:2003 says the optional elements should
appear "in the following order", and that the DTD does not enforce
this. Although I think it is in fact possible to come up with a
content model that would enforce what the prose describes, for a
variety of reasons (which I expect to go into in more detail below) a
looser content model was used.

So according to my criteria just posted (in "which takes precedence,
the prose or the schema?"), the prose of the Guidelines takes
precedence. "But how would *I* know the DTD was just left loose
because you guys are lazy?" you ask. I hear you cry. So the
Guidelines actually make this particular one explicit:

   Although not enforced by the DTD, it is a
   requirement for TEI conformance that information
   about publication place, address, identifier,
   availability, and date be given in that order,
   following the name of the publisher, distributor, or
   authority concerned  -- P4:2002 p. 913
                           http://www.tei-c.org/P4X/ref-PUBSTMT.html

I can already hear the (valid, I believe) complaint that this text
only appears in the reference section, not in the chapter that
actually deals with this (i.e., 5.2.4). I don't want to address this
problem right now. More later if people are interested.


<publicationStmt>, past: the history
------------------ ----- --- -------
Caveat: While I have spoken to some of the folks involved in its
creation, I was probably still using GML, let alone SGML, let alone
TEI, when the P2 content model and definition of <publicationStmt>
was created. (I have not researched as far back as P1, when this
element was called <publication.statement> -- there is a point of
diminishing returns.)

In all 5 versions of the Guidelines discussed herein (P2, P3:1994,
P3:1999, P4:2002, and P4:2003) the prose has the same sentences
discussing the order of the children of <publicationStmt>, and how
they relate to each other:

    At least one of these three elements [<publisher>, <distrib-
    utor>, or <authority>] must be present, ... Each may be
    followed by one or more of the following elements, in the
    following order:
    ...
    Note that the dates, places, etc., given in the publication
    statement relate to the publisher, distributor, or release
    authority most recently mentioned.

I agree that this is a somewhat ambiguous description. Before I delve
into possibilities, let's look at how the DTD has reflected this
constraint over the releases of the Guidelines.

Here is the history of the structured branch of the content model of
<publicationStmt> (remembering that in each case, the content model
allows for a series of one or more <p> elements to be used for a
prose description as an alternative to the structured elements). The
content model fragments are pre-compiled (i.e., the n-dot parameter
entity references have been resolved) and whitespace has been
liberally changed; also the references to the Incl content model
class have been removed from the P4 version (remember that the P4
content models need to include the "globally included" elements via
the Incl class directly as there are no inclusion exceptions in XML).

P2 content model:
        (
          ( publisher | distributor | authority ),
          place?,
          address?,
          idno*,
          availability?,
          date?
        )+

P3:1994 content model:
        (
          ( publisher | distributor | authority )
        &
          ( pubPlace?, address?, idno*, availability?, date? )+
        )+

P3:1999[1], P4:2002, and P4:2003 content model (all the same):
        (
          publisher | distributor | authority | pubPlace
          | address | idno | availability | date
        )+

In order to make the discussion less verbose, I'm going to classify
all the children elements into one of two groups. The "lead" element
types are <publisher>, <distributor>, and <authority>; the "detail"
element types are <pubPlace>, <address>, <idno>, <availability>, and
<date>.

P2
--
So the P2 content model seems to make some sense. It permits one or
more sequences of elements, the first of which must be one of the
three "lead" element types, and a sequence of "detail" elements may
follow in a prescribed order. Although each of the "detail" element
types is optional, if it does occur, it has to be in a particular
spot, most notably *before* the next "lead" element. Thus we could
infer the convention that "detail" elements describe the publisher,
distributor, or authority named in the closest "lead" element that
precedes them. (Although we need not, as it was spelled out in the
prose.)

So it permits

(P2.a) <publisher>, <pubPlace>, <idno>, <date>,
       <publisher>, <pubPlace>, <address>, <idno>, <idno>, <idno>, <date>,
       <authority>, <availability>

(P2.b) <publisher>

(P2.c) <distributor>, <address>,
       <publisher>, <pubPlace>, <idno>, <date>,
       <authority>, <address>, <idno>, <availability>

but disallows

(P2.z) <publisher>, <pubPlace>, <date>, <idno>,
       <publisher>, <pubPlace>, <address>, <idno>, <idno>, <idno>, <date>,
       <authority>, <availability>

because <idno> is not permitted after <date> in the 1st line;

(P2.y) <idno>

because one of the "lead" element types must be present; and

(P2.x) <distributor>, <address>,
       <publisher>, <pubPlace>, <pubPlace>, <pubPlace>, <idno>, <date>,
       <authority>, <address>, <idno>, <availability>

because <pubPlace> is not repeatable.

So this content model seems to represent one interpretation of the
prose pretty well.

P3:1994
-------
But then P3 came along, and the content model ... well, let's just
say it leaves a bit to be desired. I don't know the impetus for this
change (again, before my time), but I suspect that there were two
underlying forces pushing for it:

1. The P2 content model permits only one of each of the "detail"
   element types, except <idno>, to be associated with a particular
   "lead" element type. In particular, only 1 <pubPlace> per
   <publisher>. But if you take a look at the title page of most any
   book, there's a good chance that more than one city is listed as
   the place of publication. Let's see, I'll just pick one at random
   off my shelf here ... ah!, the TEI _Guidelines for Electronic Text
   Encoding and Interchange_ and look ... whaddaya know, four cities
   listed, not even on the title page, but on the *cover*: Oxford,
   Providence, Charlottesville, Bergen. Or perhaps Steve DeRose's
   _The SGML FAQ Book_ ... one publisher (Kluwer Academic Publishers)
   and three cities (Boston, Dordrecht, London) listed on the title
   page.

2. The P2 content model put the publisher first, then the place, then
   the date. But standard bibliographic description practices (ISBD,
   CMS, MLA[2]) call for the place first, then the publisher, then
   the date. Now we all know that in the Big Picture it makes no
   difference what order such elements are in ... they can be
   re-arranged at will without any information loss. But we also know
   that in the trenches it can help quite a lot for data capture if
   the elements are in the same order on your screen as they are on
   the page. Since the order is arbitrary, why not allow it to match
   what the data capture folks would prefer?

Again, I don't know that these were the reasons the content model was
changed, but it does make some sense. The two major changes to the
content model were to

1. allow the "detail" element group to repeat; and
2. allow the order of the "lead" element and the "detail" element(s)
   (if any) to be reversed.

change #1: detail repeat
------ --- ------ ------
First let's examine change #1 in isolation. Presume that the ampersand
connector in the P3:1994 content model was actually a comma:
        (
          ( publisher | distributor | authority ),
          ( pubPlace?, address?, idno*, availability?, date? )+
        )+
Because each and every "detail" element is optional (whether
repeatable or not is unimportant for this part of the discussion), the
fact that the set of them (in the correct order) can be repeated means
that these elements will satisfy the content model even if they are
*not* in the right order.

E.g., let's take the following short sequence of elements:

   <publisher>, <availability>, <idno>

This sequence is invalid against P2 (and I daresay incorrect) because
<idno> appears after <availability>. But it is valid against P3:1994
because of the repeat of the (everything optional) "detail" group. To
see why, consider it from the parsers' point of view.

* The <publisher> matches the 1st element of the "lead" element group,
  we're happy;

* The <availability> matches the fourth element of the "detail"
  element group. Since the three elements that precede it in this
  group (namely <pubPlace>, <address>, and <idno>) are all optional,
  the fact that they are not present in the instance is fine, we're
  happy;

* The <idno> can't be after an <availability> in this first
  occurrence of the "detail" element group, so we must be up to a
  second occurrence of this repeatable group -- indeed it matches the
  3rd element in this group, but since both of the elements in front
  of it in the "detail" group are optional, the fact that they were
  not present in the instance is fine, we're happy.

If that isn't clear to a lot of folks perhaps I should see if Matthew
Brook O'Donnell can create some nifty SVG graphics to represent it.

So the net effect is that

          ( publisher | distributor | authority ),
          ( pubPlace?, address?, idno*, availability?, date? )+

is the same as

          ( publisher | distributor | authority ),
          ( pubPlace |  address |  idno |  availability |  date )*

I haven't done the necessary content model algebra to prove this yet,
but I'm pretty confident that I'm right.

change #2: ampersand between "lead" and "detail"
------ --- --------- ------- ------ --- --------
So now to review the second change in isolation. Remembering that this
is a change from P2's content model, I'll need to rewrite that model a
bit to isolate the change.

P2, repeated so you don't have to scroll up:
        (
          ( publisher | distributor | authority ),
          place?,
          address?,
          idno*,
          availability?,
          date?
        )+

I hope we can all agree that no changes are made to the set of element
sequences that are valid against the content model by putting the
"detail" elements inside a pair of parentheses and writing them on one
line:

        (
          ( publisher | distributor | authority ),
          ( place?, address?, idno*, availability?, date? )
        )+

No changes: still says 1 "lead" element type followed by
 0 or 1 <place> followed by
 0 or 1 <address> followed by
 0 or more <idno>s followed by
 0 or 1 <availability> followed by
 0 or 1 <date>.

Now if we just change <place> to <pubPlace>, we can start talking
about what happens when we change the comma (SEQ or sequence
connector) between the "lead" and "detail" groups to an ampersand (AND
or and connector). The and connector ("&") is an SGML construct not
available in XML DTDs. It means "what's on my left *and* what's on my
right, in either order". Thus

    ( A & B )

is equivalent to

    (  ( A, B )  |  ( B, A )  )

So, looking at change #2 in isolation means talking about

    (
      ( publisher | distributor | authority )
    &
      ( pubPlace?, address?, idno*, availability?, date? )
    )+

which is the same is P3:1994 without the "+" repeatability of the
"detail" group.

So for any one of the repeatable outer group, either the (required)
"lead" element type or the sequence of (optional, <idno> repeatable)
"detail" element types can come first.

It's not at all clear (at least, not to me) what the semantics of the
various element sequences permitted would be. We may want to think of
each iteration of the repeatable outer group as the information
chunk about one particular "lead". If that's the case, though, we have
(in the absence of prose restrictions, of course) lost the capability
to ascertain which "detail" elements correspond to which "lead"
elements in some situations. E.g., consider the passage

      <publicationStmt>
        <publisher>Starfleet Headquarters</publisher>
        <pubPlace>San Francisco</pubPlace>
        <address>
          <addrLine>Promenade #179</addrLine>
          <addrLine>Space Station DS9</addrLine>
        </address>
        <date value="2369-07-27">Stardate 46570</date>
        <distributor>Bajoran Planetary Security Agency</distributor>
      </publicationStmt>

Any (24th century) human can immediately tell that the <pubPlace> is
associated with the <publisher> and that the <address> is associated
with the <distributor>. But no XML parser will be able to figure this
out. To a parser the <address> is just as, if not more, likely to be
the 2nd element of the 1st "detail" group (and thus refer to the
<publisher>) as it is to be the first occurring element of a second
"detail" group that is associated with a second "lead" group (which
the parser isn't even close to yet :-)

Note that reversing the last two children guarantees that the parser
thinks <address> is associated with <publisher>:

      <publicationStmt>
        <publisher>Starfleet Headquarters</publisher>
        <pubPlace>San Francisco</pubPlace>
        <address>
          <addrLine>Promenade #179</addrLine>
          <addrLine>Space Station DS9</addrLine>
        </address>
        <distributor>Bajoran Planetary Security Agency</distributor>
        <date value="2369-07-27">Stardate 46570</date>
      </publicationStmt>

since now the <date> becomes the "detail" group associated with
<distributor>, forcing the <pubPlace> and <address> to be the "detail"
group associated with <publisher>.

Conversely we may prefer to think of the semantics of the permitted
sequences of elements as we did before: that each "detail" element
describes the "lead" element that preceded it. And, in fact, this is
exactly what the prose of the Guidelines (P2 through P4) tells us:

    Note that the dates, places, etc., given in the publication
    statement relate to the publisher, distributor, or release
    authority most recently mentioned.       -- P4:2002, pg 89

But then what do we make of a sequence that starts with a "detail"
element?

Combined
--------
So when we put changes #1 and #2 together, the net result is a content
model that's equivalent to
        (
          ( pubPlace | address | idno | availability | date )*,
          ( publisher | distributor | authority ),
          ( publisher | distributor | authority | pubPlace
            | address | idno | availability | date )*
        )
which might be easier to read if we use my shorthand instead:
        (
          detail*,
          lead,
          ( lead | detail )*
        )
which doesn't really constrain much, now does it? All it requires is
that there be at least one "lead" element. Everything else is up for
grabs. (Again, I haven't done the formal content model algebra to
prove this.)

P3:1999
-------
It's my guess (remember, I wasn't there) that when revamping the
Guidelines for the 1999 release someone realized how messed up the
P3:1994 content model was. Since the SGML AND ("&") had to be removed,
the content model had to be rewritten anyway. Certainly it could have
been written as above with only OR connectors, and would then have
expressed the equivalent constraints. But that would have required
that whoever was doing this jump through the mental hoops we've just
been through (actually slightly worse -- remember that the
"globally included" elements also needed to be added to the content
model[3]), and the net result would have expressed constraints only a
smidgen stricter, and only a smidgen closer to the desired result,
than the easy-to-write and easy-to-understand repeatable OR group we
ended up with. Since most of the restrictions would have to come from
the prose Guidelines in either case, why not go with the easier on the
eyes version?

P4
--
As you might guess, the P4 content model is just copied from P3:1999.


<publicationStmt>: interpretation
------------------ --------------
To be honest, I'd like to know what the prose means, too. Here it is,
excerpted from P4, but note that this prose has remained unchanged,
at least in the important parts, since P2:

    The <publicationStmt> element is the fourth component of the
    <fileDesc> element and is mandatory.
    ...
    It may contain either a simple prose description, or groups
    of the elements described below:
    [ <publisher>, <distributor>, <authority> ]
    <!-- para on what the above elements are for -->
    At least one of the above three elements must be present,
    unless the entire publication statement is given as prose.
    Each may be followed by one or more of the following
    elements, in the following order:
    [ <pubPlace>, <address>, <idno>, <availability>, <date> ]
    Note that the dates, places, etc., given in the publication
    statement relate to the publisher, distributor, or release
    authority most recently mentioned. If the text was created
    at some date other than its date of publication, its date of
    creation should be given within the <profileDesc> element,
    not in the publication statement. Give any other useful
    dates (e.g., dates of collection of data) in a note.

The most straightforward interpretation, and likely the "correct" one
is that "one or more of the following" means one or more single
occurrence of each of the following (in the prescribed order). I.e.,
being followed by "one" would be, e.g.,
    <publisher>, <pubPlace>
being followed by "two" would be, e.g.,
    <publisher>, <pubPlace>, <date>
etc. The P2 content model reflects this (except for the repeatability
of <idno>) quite well. I.e., this interpretation calls for the
"details" branch of the content model to be
   ( pubPlace?, address?, idno?, availability?, date? )
This seems like a pretty solid interpretation. "One or more" here
refers to element types, not occurrences of element types.

But [as Kevin begins to point out in his second post of this thread],
"Each may be followed by one or more of the following ..." could also
mean that the "detail" branch of the content model should be
   ( pubPlace+, address+, idno+, availability+, date+ )?
This also seems quite solid with respect to the prose, although it
would have been better worded "may be followed by one or more of each
of ..." -- the "may" is represented by the fact that the entire group
is optional, and the "one or more of [each of] the following" is
represented by the repeatability of each element type. However, this
interpretation seems nearly ridiculous with respect to reality. The
existence of the desire to encode an <idno> does not imply the desire
to encode all the other "detail" elements.

The following:
   ( pubPlace*, address*, idno*, availability*, date* )
is also a possibility, but less solidly so as this would force the
interpretation of "one or more of the following elements" to mean
"any number of occurrences of one or more of the following element
types", which is a bit of a stretch.

This version:
   ( pubPlace?, address?, idno?, availability?, date? )+
is another possibility, but also not too solid. Besides the lack of
any order constraint as described above, this interpretation would
require us to think that "one or more of the following elements" was
intended to mean "one or more sets of any number of the following
elements".


<publicationStmt> future: what for P5?
----------------- ------- ---- --- ---
Enough! My brain's full, and in truth, I'm barking up the completely
wrong tree. The big question isn't what did the original authors
mean, nor how to better model it with a content model. The question
is, what *should* a <publicationStmt> be? I.e., what should we do for
P5?

First, allow me to present a content model that I think comes closer
to what I think the prose of the Guidelines intended; i.e., what
P3:1994 perhaps should have had. I have made some assumptions which
previous editors or work group members may contradict:

* It makes no sense to associate a <pubPlace> with a <distributor> or
  an <authority>;

* We do want to allow for multiple <pubPlace>s to be associated with
  a <publisher>;

* We do want the <pubPlace> to precede the <publisher> to precede the
  <date>.

  (
    ( (pubPlace, address?)*,  publisher, idno*, availability?, date? )
    |
    ( distributor, address?, idno*, availability?, date? )
    |
    ( authority, address?, idno*, availability?, date? )
  )+

While this specification is, I think, far better than those in P2
through P4, and is, I believe, unambiguous, it is awfully
confusing. E.g., in
   <distributor>, <address>, <publisher>
we know that the address is that of the distributor, but in
   <distributor>, <pubPlace>, <address>, <publisher>
we know that the address is that of the publisher. Too weird.

Besides, inserting the "globally included" elements into this model
is nearly nightmarish. Here's the entire thing:

<!ELEMENT %n.publicationStmt;
(
  (%m.Incl;)*,
  (
    ( %n.p;, (%m.Incl;)* )+
    |
    (
      (
        ( %n.pubPlace;, (%m.Incl;)*, ( %n.address;, (%m.Incl;)* )? )*,
        %n.publisher;, (%m.Incl;)*,
        (%n.idno;, (%m.Incl;)*)*,
        (%n.availability;, (%m.Incl;)*)?,
        (%n.date;, (%m.Incl;)*)?
      )
      |
      (
        %n.distributor;, (%m.Incl;)*,
        (%n.address;, (%m.Incl;)*)?,
        (%n.idno;, (%m.Incl;)*)*,
        (%n.availability;, (%m.Incl;)*)?,
        (%n.date;, (%m.Incl;)*)?
      )
      |
      (
        %n.authority;, (%m.Incl;)*,
        (%n.address;, (%m.Incl;)*)?,
        (%n.idno;, (%m.Incl;)*)*,
        (%n.availability;, (%m.Incl;)*)?,
        (%n.date;, (%m.Incl;)*)?
      )
    )+
  )
) >

But this still doesn't address some of the basic underlying problems
of the entire <publicationStmt> as conceived, most notably how to
figure out which "detail" node is associated with which "lead" node
in an easy manner for both humans and computer software.

What I think we should do for P5 is to give the elements *content*.
E.g. (without the parameter entities nor global inclusion stuff):

<!ELEMENT publicationStmt ( p+ | ( publisher | distributor | authority )+ ) >
<!ELEMENT publisher   ( (pubPlace, address?)*, name, idno*, availability?, date? ) >
<!ELEMENT distributor ( name, address?, idno*, availability?, date? ) >
<!ELEMENT authority   ( name, address?, idno*, availability?, date? ) >

(Remember, though, that in P5 this would be expressed in RelaxNG.)
Two obvious problems:

* the reference to "name" should probably be "( name | orgName |
  persName | rs )" or some such;

* the element declared with name "publisher" above could not really
  be called "publisher" unless we are prepared to live with the new
  content model for <publisher>s inside <bibl>s, <docImprint>s, and
  <imprint>s too.

I am reasonably confident that the former can be solved by creating
an appropriate class for naming elements, and populating it with only
those that are available given the tagsets chosen.

Remember that the above is just an example; it may make a lot more
sense to have <address> before <pubPlace>, or <date> immediately
after <name>, or whatever. The point is that by giving the "lead"
elements structure, we avoid a lot of the ambiguities of the previous
content models. Then, of course, we need to have the editors come up
with prose that matches. Oh Lou ...


Appendix
--------
In RelaxNG the example recommended content models that give the lead
elements content would perhaps look something like the following, but
don't take my word for it, I am a RelaxNG novice.

        content.publicationStmt =
          attributes.publicationStmt,
          (
            (p, class.Incl*)+
            |
            (
              ( publisher | distributor | authority ),
              class.Incl*
            )+
          )
        content.publisher =
          attributes.publisher,
          (
            ( (pubPlace, class.Incl*), (address, class.Incl*)? )*,
            (class.name, class.Incl*),
            (idno, class.Incl*)*,
            (availability, class.Incl*)?,
            (date, class.Incl*)?
          )
        content.distributor =
          attributes.distributor,
          (
            (class.name, class.Incl*),
            (address, class.Incl*)?,
            (idno, class.Incl*)*,
            (availability, class.Incl*)?,
            (date, class.Incl*)?
          )
        content.authority =
          attributes.authority,
          (
            (class.name, class.Incl*),
            (address, class.Incl*)?,
            (idno, class.Incl*)*,
            (availability, class.Incl*)?,
            (date, class.Incl*)?
          )

Although it likely makes sense to abstract the contents a level
further since there is significant overlap.

(Note that the above example RelaxNG is not quite right, as the
class.Incl elements are not permitted as the first child of any of
the defined elements.)


Notes
-----
[1] The alpha version of P3:1999 distributed on CDs at ACH/ALLC at
    the University of Virginia had a problem in the teihdr2.dtd file
    -- the element declaration for <publicationStmt> is missing. The
    content model here appears in both the P3X and plain-text
    versions (files p3hd.p3x and p3hd.doc) of the Guidelines.
[2] I don't have ready access to any of these books right now, so
    please let me know if I'm wrong on this.
[3] Not needed when <publicationStmt> appears as a child of <fileDesc>
    the eldest child of <teiHeader>, but <publicationStmt> can also
    occur as a child of <biblFull> which can occur as a descendant of
    <text> in a <p>, <ab>, or any similar element (including as a
    child of a metrical line! Are we going the way of Perl poetry?
    Will encoders soon be whipping up <biblFull>s that scan and rhyme?
    Sigh.)

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996
September 1996
August 1996
July 1996
June 1996
May 1996
April 1996
March 1996
February 1996
January 1996
December 1995
November 1995
October 1995
September 1995
August 1995
July 1995
June 1995
May 1995
April 1995
March 1995
February 1995
January 1995
December 1994
November 1994
October 1994
September 1994
August 1994
July 1994
June 1994
May 1994
April 1994
March 1994
February 1994
January 1994
December 1993
November 1993
October 1993
September 1993
August 1993
July 1993
June 1993
May 1993
April 1993
March 1993
February 1993
January 1993
December 1992
November 1992
October 1992
September 1992
August 1992
July 1992
June 1992
May 1992
April 1992
March 1992
February 1992
January 1992
December 1991
November 1991
October 1991
September 1991
August 1991
July 1991
June 1991
May 1991
April 1991
March 1991
February 1991
January 1991
December 1990
November 1990
October 1990
September 1990
August 1990
July 1990
June 1990
April 1990
March 1990
February 1990
January 1990

ATOM RSS1 RSS2



LISTSERV.BROWN.EDU

CataList Email List Search Powered by the LISTSERV Email List Manager