![[H O M E : Emblem Project Utrecht]](/static/images/rd-small.gif)
This document describes the customisations to the TEI DTD’s we found to be necessary or convenient.
We have not used the modification mechanisms described in Chapter 29 of the TEI Guidelines. Instead, we used a Pizza-chef generated DTD and modified it manually. We avoided the prescribed modification mechanism for two reasons: (1) time constraints (this is a large project with a lot of other things to focus on), and (2) foresight. In the future we hope to, not use any of the TEI-supplied DTD’s, but rather a minimal DTD. This DTD, while being TEI-conformant, will describe only the elements and attributes we actually use, in as much detail as possible.
Some of the changes were introduced to check whether the XML files conform to the EPU encoding guidelines. Validation of the XML files will return an error if the XML file does not conform to the modified DTD. These modifications have no effect on the document’s level of TEI-conformance.
Other modifications, mostly the introduction of new attributes, will make the documents technically non-conformant. This means that they will not validate against the original TEI DTD’s. However, trivial or very simple transfomations will result in conformant documents.
There is one modification with more serious consequences, the introduction of the titleBlock-element. However, here we have followed established practice at the Women Writers Project and feel this justifies our choice.
To avoid duplication of information, this document discusses the changes made to the DTD without giving complete detail about the new definitions. If you want to check the actual element or attribute definitions, please check the DTD source file vaentei.dtd.
We have added the url attribute of the <xref> and the <xref> element.
We did this to make it easier to add links to website to our bibliography- file. Instead of listing website adresses as entities in a seperate DTD, we are from now on placing them directly into the bibliography-file - as it is done in P5 too.
On the definition of the id attribute on the biblStruct element, we changed the value #IMPLIED to #REQUIRED.
We used the <biblStruct> element in the bibliography, and want to point out these elements from the editions. Thus, the elements should have a unique identifier. Validating the XML file will return an error if the id attribute is missing.
On the definition of the type attribute of the <xref> element, we have changed the value CDATA and replaced it by an enumerated list of values.
We used the <xref> element, among other things, to point to sources and parallels for emblem elements. The type attribute is used to indicate whether we refer to a parallel, a source or an indirect source, etc. Validating the XML file will return an error if the type attribute does not have one of the agreed values.
On the definition of the role attribute on the <editor> element, we changed the value CDATA and replaced it by an enumerated list of values.
We used the <editor> element, as explained in the bibliography encoding guidelines, for all those who bear secondary responsibility for a work’s content. The role attribute indicates which type of responsibility, with inconsistencies avoided by enumerating the alowed values in the DTD. Validating the XML file will return an error if the role attribute does not have one of the agreed values.
On the definition of the type attribute on the <note> element, we changed the value CDATA and replaced it by an enumerated list of values.
Both in the emblem files and in the bibliography, we used the <note> element for a variety of purposes, as explained in and NOTES. The type attribute is used to indicate the type of note and is used in the generation of the HTML files. Validating the XML file will return an error if the type attribute does not have one of the agreed values.
We have added a status attribute to the definition of the <div>, <note> and <figDesc> elements.
The status attribute is used to indicate whether a particular element is ready for publication. It controls whether and how the element will be shown on the public website.
On the <interpGrp> element we added a typedut attribute, and on the <interp> element a valuedut attribute.
We used the <interpGrp> and <interp> elements to associate keywords and interpretational encodings with emblem elements. The typedut and valuedut attributes are meant to provide a Dutch equivalent to the English values provided in the type resp. value attributes.
On the <xref> element we have added a type attribute.
We want to present the user with the option to selectively apply different types of regularisation. Accordingly, we need an attribute to identify whether a particular regularisation concerns spelling, punctuation, or spacing. See ff.
On the <text> element we added a type attribute.
We decided to reserve the upper level <front> and <back> elements for editorial material. The emblem book texts (both the emblems and preliminary material) are encoded as <text> elements within a <group>. We introduced a the type attribute on the <text>’s in order to distinguish emblem <text>’s from other <text>’s. See .
We have introduced an <ana> element and allowed its use within <text>, <figure>, <biblScope> and <ptr> elements.
The universal ana attribute is of type IDREFS. XSLT has no easy way to parse a string consisting of multiple values. Therefore, we introduced the <ana> element, which carries the attribute refers of type IDREF. Rather than code multiple values within a single ana attribute, we now code multiple <ana> elements, each with a single value. See .
On the <xptr>, <xref>, <ptr>,<ref> elements we added a source attribute.
We used these elements, among other things, to point out sources and parallels for emblem elements. The source attribute should be used to indicate who is responsible for this reference. If we found the reference in an item described in the bibliography, the <xref>’s source attribute will contain the id attribute of the relevant <biblStruct>. If we found the parallel ourselves, the attribute will contain our initials. We have, however, been rather relaxed in using this attribute.
We introduced the <titleBlock> element as an alternate form to the <titlePage> element, and allowed its use within the <div> elements.
Many elements which the TEI DTD’s allow only on title pages may occur elsewhere, the <imprimatur> element is an example. Following the example of the Women Writers Project, we used the <titleBlock> element within <div>’s to account for this situation.
We have changed the content model for the <change> element to allow for multiple <item> elements.
In the documents’ change logs (in the <revisionDesc> element) it is more convenient to group several <item>’s under a single <change>. These items will share their <date> and <respStmt> information.
We have introduced a <tune> element for tune indications, and changed the <lg> content model to allow for its presence.
The issue of tune indications was raised once on TEI-L (not by us), with no satisfactory outcome. Use of the general-purpose <opener> element does not allow retrieval of tune indications, which seems an obvious desideratum.
| © This work is licensed under a Creative Commons License. |