I'm thinking that either an @status on edition or an optional <status> 
child of editionStmt is the way to go on this. As far as I can see that 
answers both Sebastian's original case for ="expired" and Martin's case 
for ="proofed" while addressing James's point about the scope of the 

So as a document went through various revisions, either the content of 
the status element or the content of the @status on edition would change:

<edition status="draft">First</edition>
<edition status="proposed">First</edition>
<edition status="copyedited">First</edition>
<edition status="proofed">First</edition>
<edition status="release candidate">First</edition>
<edition status="published">First</edition>
<edition status="revised">First</edition>
<edition status="deprecated">First</edition>
<edition status="withdrawn">First</edition>
<edition status="reinvigorated">First</edition>

I think you might find that many of these stages also involve revisions, 
and so would probably also show up as change under revision statement; 
but not all status changes involve revisions: a thesis can be 
@status="submitted" and then @status="approved" without any changes to 
the text (if you're lucky ;). Likewise, documents can expire without 
changes from when they were still active.

So that's my guess. Seems like a useful feature request.


James Cummings wrote:
> Sebastian Rahtz wrote:
>>> Alternatively, you could use secret codes for your @n values on 
>>> edition I suppose (if the @n value starts with X it's an expired 
>>> edition... OK, no that is disgusting and I apologise for even 
>>> mentioning it)
>> well, that was my[1] plan, actually! you guessed right first time.
>> [1] ok, James Cummings' plan .....
> I seem to recall that I winced when you mentioned it, and said 
> something about "well that is the kind of abuse people make of @n".  
> Strange how we seem to have different recollections of this. :-)
> As TEI documents are using increasingly for web publication, it seems 
> reasonable that there should be a clear consensus on where and how to 
> record both version and status information of the document as it 
> passes through an internal workflow. I'm not making an argument for 
> any of the proposed solutions, but suggesting that we should decide 
> what *is* the right way to do it, and if we need new 
> elements/attributes then add them.  I see the current 'status' of a 
> document as metadata about its place in a revision process.  But a 
> @status attribute on <revisionDesc> would imply the status of that 
> <revisionDesc>, would it not? There used to be a @status on 
> <teiHeader> (if memory serves) but that was again the 'status' of the 
> header itself, not the document as a whole.
> Just my two pence,
> -James

Daniel Paul O'Donnell
Associate Professor of English
University of Lethbridge

Chair and CEO, Text Encoding Initiative (
Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America
President-elect (English), Society for Digital Humanities/Société pour l'étude des médias interactifs (
Founding Director (2003-2009), Digital Medievalist Project (

Vox: +1 403 329-2377
Fax: +1 403 382-7191 (non-confidental)
Home Page: