Print

Print


Dear Sebastian,

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 
>considerable influence
>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 
steer itself.

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.

>[1] oh, you want the precise spec of processing model? er um well,
>just read the code, Luke....

Yes, well.... :-)

Cheers,
Wendell



======================================================================
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
======================================================================