I have encoded a small collection of medieval accounts with TEI P5 and I adopted exactly the same strategies that Paul mentioned (using <item> for the totals, and putting <add> inside <item> for added entries (and added totals).

I think there is so much irregularity in medieval accounts that it would be unwise and asking for trouble if you wanted to model these sources in more detail. 

I have not done this yet, but if I was going to do any further statistical processing of the data, I would assign xml:id to all these <item>s, which would then allow me to specify relationships between the different entries, rubrics, chapters etc.


Dr. Godfried Croenen
Reader in French Historical Studies
Research Fellow of the Bibliographical Society of America
Department of Cultures, Languages and Area Studies 
University of Liverpool 
Chatham Street 
L69 7ZR
United Kingdom
Tel: +44 (0)151 794 2763
Fax: +44 (0)151 794 2357
e-mail: [log in to unmask]
Personal webpage:
Online Froissart:

-----Original Message-----
From: TEI (Text Encoding Initiative) public discussion list [mailto:[log in to unmask]] On Behalf Of Paul F. Schaffner
Sent: 30 November 2012 20:38
To: [log in to unmask]
Subject: Re: trailers and added list items

I don't now remember if it is a workaround, a kludge, a customization lost to memory, or an outright abuse, but we encounter accounts like this all the time -- with subtotals, added entries, and so forth. We

-- use both lists and tables, depending on their 'horizontal' complexity,
    but are probably a little more inclined to use tables.
-- do not use <trailer> for totals and subtotals, but use (in tables)
    <row role="total"> or <cell role="total"> and (in lists) <item
    role="total">. This allows the list to continue on past the total
    or subtotal to further subtotals or totals. We interpret 'total'
    quite generously to mean any kind of pause-to-take-stock. Embedded
    heading-like material is likewise dealt with by <cell role="label">
-- since our materials are printed, <add> is only rarely an issue;
    so far allowing <list> within <add> and <add> within <item> have
    together met all our needs.


On Fri, 30 Nov 2012, Georg Vogeler wrote:

> Hi everybody,
> I'm trying to encode a medieval account book and get stuck in the 
> attempt to model it list-like (which seemd to me the only possibility 
> the TEI offers at the moment for text like that). The problem results 
> from the functional role of sums.
> The easy case is
> <list>
> <head>Entries by 1335</head>
> <item>In Haydawe <measurce type="currency" quantity="100" 
> unit="lib.d.">c lib.</measure></item> ...
> <trailer>Summa <measure type="currency" quantity="600" 
> unit="lib.d.">dc lib.</measure></trailer> </list>
> It becomes difficult when the clerk later on added other entries to 
> his calculation. I would be happy to do <list> ...
> <trailer> ... sum ... </trailer>
> <add>
> <item> ... </item>
> <trailer> ... new sum ... </trailer>
> </add>
> </list>
> which would mean: In the first writing stage there is a complete list 
> with an end (the sum), and in a second some items of the list are 
> added expanding the previous list (not creating a new one).
> But the schema allows no <add> in the list and nothing can follow 
> <trailer> (which by the way doesn't change if I go more abstract and 
> use div/ab for the list).
> Is my case a case completely new to the TEI? Did I miss something? Or 
> can anybody offer a cute workaround?
> Best
> Georg

Paul Schaffner | [log in to unmask] | 316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1190