At 02:08 PM 1/2/2007, Sebastian Rahtz wrote:
>>As I've said before, I thought the P3/P4 definition had the balance
>>just about right. It pointed to validation against a DTD and
>>defined ways in which a custom DTD could vary while remaining in
>>conformance, while not relying on exclusively automated mechanisms.
>>It was not a cookie-cutter approach, but instead held projects to a
>>high standard. Conformance meant not simply formal validation as
>>such, but intellectual rigor, demonstrated through documentation
>>and explicit rationales that showed how and why modeling decisions
>>were made and applied.
>That's a consistent standpoint. I disagree fairly strongly, though. I think
>that P3/P4 provided a test for conformance which made the user feel good,
>but did little to make their documents useable by others.
I think it did far more than "make users feel good". It assured that
their intellectual decisions and justifications would be made in full
view of knowledgeable practitioners, and thus legitimated their work,
while allowing them the scope they needed both to realize their
technical and intellectual aims and to distinguish themselves by how
they did so. This was and is very important to audiences, which
include (now) grant funding agencies and (some day) tenure committees.
As for not delivering on the promise of "making their documents
usable by others", I submit that it has not been demonstrated that
ODD will ensure this any more than the older, less formal methods
did. As far as I can see, ODD does nothing at all for this except
perhaps make the documentation a bit more accessible -- assuming the
spirit as well as the letter of ODD is followed (and if it's not, all
bets are off).
So, I think you're attacking a straw man with a broom. To my mind,
the TEI is wonderful for achieving a very important kind of
interchange that machines just aren't very good at ... and the
history of HTML shows us what the other kind of interchange is good
for (not very much beyond display).
>>Ah, so you agree with me then. So, if a project has no ODD but can
>>justify their means and methods, they can yet be blessed? Will the
>>peer group be willing to acknowledge that ODD implementations are
>>no better as final arbiters than the schemas they define, and that
>>indeed there might be a category (albeit narrow) of TEI that may
>>(now or in future) have good reasons to use other mechanisms?
>Of course. But this isn't self-blessing. As the TEI project stands at present,
>we have a formally elected peer group (viz the Technical Council of TEIC)
>which makes judgements. It's a plausible compromise way of deciding
>what "peer acceptance" is, I suppose. If they say _at present_ "thou
>shalt use ODD, Wendell", then I'd argue you cannot strike out on
>your own and say "this is what
>I do and it is TEI cos I say so" - you have to use your
>to persuade that group of peer judges to go other ways as well. As indeed you
>are quite rightly doing in the forum of TEI-L.
Indeed. But I've been arguing preemptively and hypothetically, since
I think it would be a mistake for the Technical Council to rule,
without offering any alternatives, "it's ODD or bust" -- which, I
imagine, would probably lead to more occasions of "bust" than they'd
like to see -- or perhaps more to the point, of potential TEI users
and allies just deciding to jump on other bandwagons.
(It would be a different thing altogether for them to rule "we much
prefer and recommend ODD, but if there are reasons you can't use it,
technically or practically, we need to learn from these too".)
That is, I am trying to defend the good work of TEI past, present and
future by warning against letting one particularly fine engine (ODD)
drive the whole circus -- since in my experience, the finer the
engine is, the more likely it is that its drivers will try to let it
But the real test will be in the kinds of work that are enabled and
frustrated. The pity is that in the nature of things, we learn about
the successes but rarely get to ponder the failures. Many projects
have picked up TEI only to let it drop again -- or have twisted it to
the point where they don't want to show their work in what they think
of as polite (or over-polite) society. TEI could learn a great deal
if it could see into this blind spot. Indeed, TEI is good work
precisely to the extent that its developers and proselytes have said
"it's not finished yet; we have more to learn".
>>This is highly relevant. Ron demonstrated that he could make a
>>legal modification that would not pass conformant XML DTD parsers
>>due to ambiguous content models. Lou argued that this problem comes
>>with the territory, implying that there is really no good fix.
>What Ron did was a legal modification, and a proper implementation
>of ODD would have generated a legal DTD from it, as it generated
>a legal RELAXNG schema.
Yet as you know, RNG schemas can and do express models impossible to
express in DTDs. While Ron doesn't have one of those, he has
something even worse: one impossible to express in the TEI DTD
architecture as it stands due to the expansion of its parameter
entities. This implies that in order to support conformant ODD fully,
an ODD implementation would have to work around the XML modeling
architecture it is based on. Quite a feat, I submit (particularly the
part about knowing when to do this), and exactly the kind of "bug"
(or more precisely, systemic weakness) I'm concerned about.
> oh, you want the precise spec of processing model? er um well,
>just read the code, Luke....
Yes, well.... :-)
Wendell Piez mailto:[log in to unmask]
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
Mulberry Technologies: A Consultancy Specializing in SGML and XML