My apologies for the delay; awfully busy and all that.
It's interesting how conversations go - I actually considered the
part of my posting of 2000-02-22T16:13Z about TEI-Lite to be the
more important part (at least for this list), but it is my mention
of my XML conversion tool that caused all this controversy.
[Sebastian Rahtz, 2000-02-22T17:20Z]
> Translating it into XML is, excuse me, a waste of valuable time. If
> you want XML DTDs, the Pizza Chef makes them, no problem (well,
> when a couple of bugs are ironed out ...).
If it's a waste of time, it's a waste that quite a few TEI "dignitaries"
have put quite a bit of effort into thinking about, no?
> If you have brain hours to spare, *improve* the TEI. Make a UML
> specification, an XML schema, a Schematron schema, or something
> which lets more of the TEI "knowledge" be encoded formally
I'm going to stay away from this for now.
Syd> I have a routine that takes as input a file created from the
Syd> Pizza Chef, and spits out an XML version thereof.
> I am baffled. why not just get the Pizza Chef to make you an XML
> DTD straight from the oven?
Good question. Three reasons, in descending order of importance or
weight:
* I wrote this routine well before Pizza-XML was available[1]
* The aforementioned bugs that need ironing out[2]
* I can use it on non-TEI DTDs, too[3]
Syd> The generated XML is not intended for data constraint, though
Syd> (our files are constrained upon creation with SGML), but merely
Syd> to make XML applications happy.
> even more am I baffled. what applications want a DTD so badly?
Darn good question. Several folks have jumped into the conversation
listing purposes for which applications desparately need a DTD, but
most (if not all) of them fall into the "constrain the data upon
creation (or editing)" catagory, which I have explicitly said we
don't need here. The truthful answer to the specific question is
"I don't know", but there's a bit more to it than that.
I want users to be able to have XML versions of our files for
local browsing or printing. Our files have thousands of references to
hundreds of entities that are not part of the XML "standard set"
(amp, lt, gt, apos, quot), some of which are boilerplates for large
chunks of text. I'd like the user to have access to these w/o
sticking them in the internal subset. So, stick them in an external
subset of a DTD. Now, if I understand correctly, there is no
requirement that well-formed XML documents that have DTDs be valid
against those DTDs. I could just have the entity declarations that I
consider important in the external subset, and skip the rest. But
then applications that processed the well-formed document might not
read the external subset (they're not required to), and might not
substitute my boilerplate text. Besides, I'm worried that there are
people and processors out there that presume that if there is a DTD,
the document must be valid, as opposed to merely well-formed. I know
I thought this was the case for awhile.
So my solution was to create XML versions of our DTDs. Since our
documents have already been created using SGML DTDs (mostly with
Emacs/psgml; some with Author/Editor) to constrain and allow easy
entry of the data, I didn't need to worry much about content models,
thus the "ANY" approach.
BTW, I readily admit that another reason for doing all this was
that it was fun, interesting, and very educational (I learned a lot
about the XML spec while writing that routine).
Notes
-----
[1] First version was written in 1999-05.
[2] Which shouldn't be construed to imply my routine is bugless -- quite
to the contrary, but I understand and know how to work around my own
bugs :-)
[3] This is currently a low-level reason because I haven't actually
tried it on any non-TEI DTDs yet -- I had planned to, but haven't
gotten around to it yet.
|