Which Takes Precedence?
----- ----- -----------
KH> When a conflict arises, which should be considered most
KH> a) the Guidelines prose
KH> b) the fragments of DTD interspersed in the Guidelines
KH> c) a DTD as baked by the Pizza Chef
Oy vey, what a deep and multi-faceted question.
First off, let's add one to the list:
d) the DTD as delivered with the Guidelines
And now, let's explain where each comes from. The Guidelines,
including the prose and the DTDs, are stored in ODD files (XML files
conforming to an extended TEI DTD). Through a (mostly XSLT) process
of transformation, (a) with (b), and (d) are extracted from the ODD
files and assembled. The (a) with (b) are transformed into HTML, PDF,
and occasionally even TEI Lite. The PDF got made into Big Blue Books,
the HTML is available to the world on the TEI website, and the TEI
Lite version is available to members who got a TEI CD at one of the
meetings. The (d) files are (of course) plain-text, and are available
to the world on the TEI website.
But what about (c)? Baked DTDs are created by assembling the various
files of (d) in the manner indicated by the user, and any extension
files supplied by the user, and boiling the set down into one big DTD
file with all of the parameter entity references expanded (and,
because they are no longer needed, all of the parameter entity
declarations deleted). So (c) is a derivative of (d), and therefore
should not be considered as authoritative. I'd go so far as to say
such DTDs are not normative at all. (Although, like many of us, I
have to admit I treat them as such often :-)
So, (c) is out, and I claim (even though I know it is occasionally
false)-: that (d) and (b) are the same. So what about conflicts
between (a) and (b & d)?
To start with, let's make sure we agree on what a "conflict" is.
Often the prose will express a constraint that is not expressed in
the DTD because the DTD language is simply not expressive enough to
express it, or no one has gone to the trouble of making it do so. In
these cases clearly the prose of the Guidelines are authoritative.
(While in the future this will be less frequent because RelaxNG and
W3C Schema are more expressive languages, there will probably always
be some such instances.)
It is feasible to imagine that the DTD expresses a constraint that is
not mentioned in the prose because the constraint is not considered
important (although I don't think I can come up with any such
examples in TEI -- but now that I've said that I have this sinking
feeling as I rub my bleary eyes that Wendell or Michael or Lou or
someone will instantly respond listing an entire class of examples).
Also such constraints may not be expressed in the prose by mistake. In
either case the DTD is clearly authoritative.
Why, if the constraint is not important, is the DTD authoritative, you
ask? Because the Guidelines say so. The first and third bullet points
of the list in section 28.1.2 boil down to saying "the DTD is
Note also, that the fourth bullet point could be construed to boil
down to saying "the prose is authoritative". That may not be obvious
at first. It says
all modifications to meaning or use of defined
tags, and all new tags, are documented ...
[rules for how documented snipped]
So, barring a deliberate change in the use of a particular tag that
is appropriately documented ala the rules I've snipped out, the use
of any tag (which includes attributes) must not have been modified.
If the use of a tag hasn't been modified, it has to be used in the
manner that was spelled out in the prose.
So far this seems to make sense. In cases where the prose expresses a
constraint that the schema does not, the prose is authoritative; in
cases where the schema expresses a constraint the prose does not, the
schema is authoritative. That is, the constraints the Guidelines
place on documents are the union of the set of constraints expressed
by the prose and the set of constraints expressed by the schema.
However, I don't think of either of these cases (where the constraint
is expressed only in the prose or the schema, but not both) to be
true "conflicts". To me the *real* problem comes about when the
constraints expressed in the schema contradict the prose. That is,
those cases where conforming to one set of constraints means you
cannot conform to the other. This is what Micheal Sperberg-McQueen
has called "a four-alarm fire" and what I usually end up calling
an egregious error that should be corrected.
The point is that in these cases it is the specification that is in
error, and (in my current humble opinion) one should deliberately
avoid leaving an escape hatch such as "in cases of conflict the
Schema is normative" which would permit users to continue to use a
specification that is broken rather than report the error and insist
it be corrected.
 http://www.tei-c.org/P4X/ or http://www.tei-c.org.uk/P4X/
 http://www.tei-c.org/P4X/DTD/dtd.zip or
 Which I find a bit odd now that I live in a small town with only
3 fire stations.