Now let's compare this with TEI's <biblStruct>. I've done a sample encoding of the same podcast item. A number of difficulties are immediately apparent:

• Should this be an <analytic> or a <monogr>?
• Why do we need <imprint> just to get <date>?
• Why is there no natural home for the URL of the MP3 file?
• The roles of agents in <respStmts> are arbitrary. The guidelines recommend (but do not prescribe) using <resp>'s @key attribute with a range of values from MARC 21's taxonomy of terms, but this list, although long, does not include "podcaster" or "presenter".
• @type attributes for the generic <biblScope> are also arbitrary.
• For "produced by", we're using an arbitrary value in a <resp>; however, <bibl> has <sponsor> available to it, while <biblStruct> does not.

The TEI <biblStruct> has a relatively small set of generic fields available to it. When we have to encode things such as issue number or page references, we already fall back on the @type attribute (<biblScope type="pages">), and the guidelines tend to deviate from prescription to suggestion, leading to divergent practice in the community. For instance, examples in the current guidelines, on the same page, show both of these:

<biblScope>pp 1013–23</biblScope>
<biblScope type="pages">3-46</biblScope>
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBITY

I think it's clear that <biblStruct> is hopelessly inadequate as a basis for a system of encoding citations. Even if we were to put serious work into extending it with new elements and attributes, and try our best to provide exhaustive examples showing how to encode every possible type of item and piece of data we can imagine, we will inevitably fail, because the bibliographic information space is too rich, too complicated, and too mutable. The Dream of Laurent is a fantasy.

In February this year, Wendell Piez described two distinct ways in which TEI markup is used, on the TEI-L list like this:

XML encoding done for the sake of fitting data to a particular application or family of applications -- which typically require at least some forms of regularity and predictability -- and retrospective markup, which aims to *describe* documents irrespective of concerns with how regular they are, and which may be as interested in irregularities as in regularities. (Markup benefits [was: Subscriber benefits], 02-02-2010.)

In a related approach, the ad-hoc committee on encoding of bibliographic citations, of which I'm a member, began its discussions with this (among other) assumptions: that there is a difference between:

• # 2.1 Encoding citations as represented in a source document (such as a pre-existing print document)
• # 2.2 Encoding citations as part of a publishing process (such as a manuscript of a book to be published)

My contention is that this difference is not as real as we think it is -- "born digital" does not mean what we think it means -- because ALL human writing is performed in a specific style, whether rigorous or not; and that it is not helpful, because it makes us think in terms of highly-structured, database-like encoding methods such as that typified by <biblStruct>. In effect, we are always doing "retrospective markup", and we might as well accept it, and act accordingly, because actually it makes our lives easier.

Styleguides prescribe the way we actually write our text. Chicago author-date form (Chicago 15th ed. 16.107-120) requires the year, while MLA does not include the year unless there are multiple works by the same author in the bibliography (MLA 6th ed. 6.4.3). APA includes commas between the elements, and the p. prefix for page numbers; while it doesn't specifically mention volume numbers, it has an example with "chap. 2", from which I've extrapolated (APA 5th ed. 3.101). Although we could abstract all of these into some more complex structure to remove the style-specific features, why bother when we'll have to render them out in a style again anyway?

• Items are in the correct order for the styleguide rendering (Chicago author-date).
• All the punctuation is there, but outside the important data tags.
• Everything that can be marked up is marked up; we can even attempt to render "spring" in a machine-readable manner.
• The two titles are distinguished by their @level attribute; the internal structure does not need to do this (although it would be nice if it could -- I've asked for <monogr> and <analytic> to be available in <bibl>).
• We have a <ref> tag available to handle the URI.
• To render this, all we have to do is spit it out in order, unchanged.
• An agent which knows which tags to look for can still pull out all the data.

I believe we should treat born-digital journal articles in exactly the same way we treat original print or manuscript documents when we encode them. They come with built-in style, and we should accept it (or correct it if it's wrong). We should confine ourselves to tagging as many pieces of data as we can find in the text, rather than re-formatting the text to try to create a set of database records in XML, then tie ourselves in knots trying to reformat that structure back into the style that it originally had.