Wendell Piez wrote:
> 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,
no difference there with P5, then?
> 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.
Indeed. I don't recall saying it would. I am not interested in defending ODD
_per se_ here, I am interested in a much more formal definition of
to enable _some_ aspects of it to be checked by machine.
> 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
the TEI gives us a vocabulary, yes. That's great.
> ... and the history of HTML shows us what the other kind of
> interchange is good for (not very much beyond display).
and remember back before we had that. good gracious, would you
like to go back to _pre_ HTML, when you consider the truly staggering
of the last 15 years??? TEI is a speck of sand in the desert compared to
HTML has achieved. In practice, TEI documents are not _even_ interchangeable
for display. Think back on the last time you tried to combine TEI docs from
several sources - aargh. I can't even straightforwardly combine documents
for display written by myself, Lou and James from the same building,
each have their own dialect of TEI.
> 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
I think you're scare mongering, to be honest. My expectation of ever
conformance rules is that an increasing number of people use the TEI.
> -- or perhaps more to the point, of potential TEI users and allies
> just deciding to jump on other bandwagons.
It's not an "either or" thing. Since you raise the analogy of taking
away, what I am interested in is not banning whatever sport you want to play
in the local park, but in being clear what the games are. If I come upon
game with bat and ball, I want a clear sign saying "we are playing to the
rules of american baseball", otherwise I'll think its proper rounders
want to join in. If you want to invent a new game, to distinguish
yourself for a tenure
committee, then that's great, but it's only fair to everyone if you
write out those
rules in a simple, standard, way. Yes, you can define your game by just
diagrams with stick people, but why raise the artificial barrier when
else uses words?
> (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".)
it's a fine idea. but I haven't heard the technical or practical
arguments which make use ODD to express your customization
_impossible_, just sentiment.
> 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".
No disagreement there, but what does this have to do with the
about conformance or ODD?
> 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.
parameter entities in DTDs are a technical detail of the implementation,
> 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.
I think you're twisting things here. The TEI sources express themselves in
RELAXNG notation and in the class system. Anything Ron does in his
will come out into a RELAXNG scheme and work (I hope). The small technical
problem lies in converting RELAXNG schemas to DTD (and W3C schema) without
making the result invalid. The formal amongst you (Syd, we need you!)
me whether it is technically impossible to convert any arbitrary RELAXNG
to DTD; if it is not, then we just have to program it; if it is, then
we'll have to
drop DTD. After all, we're not the only people in this bind.