LISTSERV mailing list manager LISTSERV 16.5

Help for TEI-L Archives


TEI-L Archives

TEI-L Archives


TEI-L@LISTSERV.BROWN.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEI-L Home

TEI-L Home

TEI-L  March 2000

TEI-L March 2000

Subject:

Re: Is there a future for TEI ? P4 ?

From:

Syd Bauman <[log in to unmask]>

Reply-To:

Text Encoding Initiative discussion list <[log in to unmask]>

Date:

Wed, 1 Mar 2000 15:39:54 EST

Content-Type:

TEXT/PLAIN

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (74 lines)

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.

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.BROWN.EDU

CataList Email List Search Powered by the LISTSERV Email List Manager