In message <[log in to unmask]>, "A. H. van der
Weel" <[log in to unmask]> writes
>The only software we have at our disposal is free: SGMLS, Panorama Free;
>Near and Far Lite, and we have Windows 3.11 or Macintosh computers to
>work on. SGMLS appears to choke on our invocation of the relevant
>portions of the TEI DTD set in the Doc Type Declaration of the document
>instance, spouting more error messages than you could poke a stick at. A
>friendly SGML user in the computer department suggested that the TEI DTD
>needed to be actually "compiled" before SGMLS could handle it. If that
>is so, (1) what does such compiling entail; (2) why is it necessary; and
>(3) is it possible for computer half-literates such as ourselves to
>actually do so, on equipment as patently amateur as ours? And if it is
>possible, how is it actually done?
>I think I have a half-baked sort of understanding of what compilation
>might yield, that is a complete DTD which could be read and displayed on
>screen by a program like Near and Far Lite. This, I must say would be
>most welcome, since it would give a good visual representation of the
>DTD's structure. But is my understanding correct? Or is it really that
>unknown quantity that I have seen being referred to as a "DTD driver
Ther are two different things you sometimes have to do to a DTD before
it will work with SGML-ready (!) software. I will describe them in a
But first, SGMLS shouldn't need either of these techniques, since it
really does understand SGML syntax. I suspect that you simply need to
give SGMLS a bit more information. If you email me your 'driver' DTD,
the document, the command line you used, and the (start of!) the error
messages, I'll have a go at sorting out what is wrong. That bit
shouldn't be hard.
BTW, are you using the latest [N]SGMLS, which comes with the SP1.1
parser materials from James Clark (ftp-able from somewhere on his
http://www.jclark.com web site)?
So, once we have SGMLS working, you'll be able to parse your documents
and check that they are valid SGML. The problem as I see it is that you
are a bit short on tools to do the 'obvious' things: create your marked-
up documents in the first place, and view/print them out once you have
got them right.
Panorama Free is ok for browsing SGML files on the web, but won't open
local files. It might be worth investing in Panorama Pro, which really
isn't that dear.
You could do with an editor of some sort. I've written lots of SGML by
hand myself, but having to type in all the tags by hand soon palls!
Also, you can get some _really_ interesting parser error messages that
way! WordPerfect 7.0 has built-in SGML support if you happen to have
that software lying around. SoftQuad at least have heard of educational
discounts - they produce Author/Editor.
Retournons a nos moutons:
Onve you acquire some software other than SGMLS, you probably _will_
need to do something to the DTD. The two things you might do are:
1) normalization. This involves passing the DTD through a program which
creates a single DTD file, containing all the element and attribute
declarations you require, which are currently scattered around 30 or so
separate files. I have written a utility (in the absence of anything
better!) which does this task, and in the process removes from content
models any mention of elements which are not actually used in 'your'
application of TEI. The reason for doing this is that some software
(Author/Editor in particular) will consider these elements an error, and
will refuse to play. Normalization may also be required for Near and
Far Lite: I'm not sure.
You can download my normalizer from:
(Use binary ftp to get this file, which is a DOS self-extracting
This is my description of the normalizer:
"NORMDTD is a DOS (yes!) program that reads a valid SGML DTD, even a
TEI-like one that uses marked sections and multiple input files, and
generates a single file containing a normalized version of that DTD.
The element content models in this normalized DTD will not contain any
references to elements that are not declared, and so it can be used by
highly-strung SGML packages such as RulesBuilder that refuse to process
TEI applications (in particular) for this reason. In fact, having a
normalized DTD in a single file can be helpful for a number of reasons,
to a variety of SGML applications.
The command syntax is:
NORMDTD DTD-file [output-DTD-file]
If you don't specify the output-DTD-file, NORMDTD will create a file for
you with the same name as the source DTD but suffix .DTN. If that file
already exists it will refuse to run.
Having run NORMDTD, you should run a parser past the resulting DTD to
check for 'hanging' separators and ambiguous context models I wasn't
clever enough to strip out. A small number of hand-edits will be
required for a typical TEI application.
The software has been known to hang my PC when presented with an invalid
DTD: it's wise to parse your TEI application and check it's clean before
trying to normalize the DTD.
I don't want any money for this software, and on the other hand I don't
take any responsibility for anything it might do to machines, data,
pets, etc. It has worked on all the valid DTDs I have tested it on, but
I make no claim for 100% SGML-conformance. If you do have problems, let
me know via email ([log in to unmask]) - I'll help if I can."
2) compilation. Some SGML software (Author/Editor again!) won't work on
a DTD directly, but requires a 'compiled' version. In this case you
will usually be provided with a program (e.g. RulesBuilder) to produce
the compiled form. So don't worry about this.
>But perhaps the most burning question is, is it possible for mere
>textual scholars in a language and literature department to use TEI at
>all without expert help? We don't wish to burden busy colleagues with
As I understand it, you are very much mainstream TEI users. Go for it!
SGML and Museum Information Consultancy
[log in to unmask]
3 Midfields Walk
West Sussex RH15 8JA
tel. (44) 1444 232067