- gutvol-d - lists.pglaf.org

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol 13, Issue 22)
by Lee Passey 24 Aug '05

24 Aug '05

Joshua Hutchinson <joshua(a)hutchinson.net> wrote: > There is a concept that Marcello and I have discussed of markup > "levels". When it comes to something like TEI, there are so many ways > you can add meta data it is completely daunting at times. In this > example, yes, a more specific markup could have been used. But, in > the final render, it works just fine as <p> blocks. But, you see, it doesn't. On my PocketPC, and in all dedicated e-book programs on my desktop computer, <p> elements (in HTML of course) have the first line indented, and there is no blank space between paragraphs. In this case your glossary just looks odd: there is an indented word or phrase, then another indented word or phrase, then another indented word or phrase, most of which are not complete sentences (although every once in a while there is a complete sentence thrown in just to confuse me). There is no typographical convention that indicates which is the term and which is the gloss. Of course I can figure it out relatively easily, but to do so I have to exit "immersive reading" mode and go into "copy editing" mode, which is disruptive to my reading experience. Had you created the list as a "<list type="gloss"><label>word</label><item>definition</item>", your XSL script could have transformed it into "<ul><li><strong>word</strong>: definition</li>", and preserved all the typographically conventions I have come to expect. As it is, these fragments are identified as paragraphs, and XSL scripts and CSS style sheets have to treat them in the same way they treat real paragraphs. I have never understood the resistance to the notion that text blocks with indeterminable semantics should be identified as <div> rather than <p>. It's a simple change in mindset. When in doubt, use <div>. Look up the definition of the word 'paragraph' in a dictionary. If you don't think you could convince your English (or any other language for that matter) teacher that the block of text satisfies the definition, use <div> (or some other more appropriate element), not <p>. This, I think, is a good example of the distinction between correctness and validity. I could mark up a phrase as "Four <term id="score">score</term> and <gloss target="score">seven</gloss> years ago ..." and it would be valid, although it would not be correct, as the word 'seven' is not really a gloss for the word 'score'. There are times when it is valuable to know that a certain block of text is, in fact, a paragraph. Suppose, for example, that someone might want to create an annotation to accompany <title>The Kitáb-i-Aqdas</title>. He or she might want to preface some text with "if you look at the second paragraph following header 77 ..." If the user has a dt edition, finding this passage is fairly easy: flip through the book for something that looks like a header and is numbered 77, and count the paragraphs that follow. If there are only a few paragraphs after header 77 and before header 78 this is quite easy. If you're looking for the 935th paragraph following header 77 it can quickly become tedious. Luckily for us, tedious is something that computers do very well. Unluckily for us, Bowerbird has not yet released his algorithm for determining whether a block of unstructured text is a paragraph. So for today, we must rely on the coders to correctly identify which blocks are paragraphs, and, just as importantly, which blocks are not paragraphs. If every indeterminate block of text is marked as a paragraph, then the value of the <p> tag is lost; it has just become a synonym for <div>, and is redundant. As the pointed man in the pointless forest said to Oblio, "A point in every direction is as good as no point at all." So, if being conscientious about only identifying as a paragraph that text which really _is_ a paragraph adds value to the file (perhaps not to you, but to someone, and if you didn't want this file to be useful to someone else you wouldn't be doing it in the first place), and if it is just as easy to be discriminating about paragraphs as it is _not_ to be, why not do it? > Another example is a text with foreign words interspersed throughout. > Often, those words would be printed in italics in the original book. > Now, the simplest markup in TEI would be to put <hi > rend="italics">around</hi> the word. But you could also mark the word > with a <foreign lang="en">foreign</foreign> tag. In the final render, > it would look exactly the same, but the second option provides more > specific metadata. You could even go further by provide a translation > of the foreign word inside the attribute (the markup escapes me at the > moment). > > The markup that would cover what PG currently has would be want I > would call a "level one markup" and that is the minimum, obviously, > that a TEI could be marked to. Level two would be given a little more > metadata, but nothing drastic. Maybe marking certain words as foreign > instead of italics. Marking a letter as such instead of just a block > of indented paragraphs. etc. etc. > > Level three would be going the extra, extra mile. It's the kind of > markup I don't expect to see, but is possible in TEI. I can completely agree with this notion of markup levels, but it seems to me that the thing that should distinquish the levels is completeness, not correctness. Documents at every level should be correct, even if not complete. In your example, the use of the <hi> tag tells the user (or more accurately, his or her software agent) "this text was italicized in the original text, but I am unable or unwilling to tell you why." The markup is incomplete, but it is not incorrect. If you were to mark up a block quotation with the <div> tag you are telling the user agent "this text was set aside as a block in the original text, but I am unable or unwilling to tell you why." I can live with that. But if you mark up a block of text with the <p> tag you are telling the user agent "this block of text contains one or more compete sentences, and deals with a single thought or topic or quotes one speaker's continuous words." Marking up a definition term as a paragraph is as incorrect as marking up the word 'seven' as a gloss for the word 'score.' Please don't let the reasonable need to tolerate incompleteness become an excuse for incorrectness. > I expect most TEI documents we post will fall in level one or level two. > > Josh

1 0

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol 13, Issue 22)
by Lee Passey 24 Aug '05

24 Aug '05

Jon Noring <jon(a)noring.name> wrote: >Lee Passey wrote: > [snip] >>Well, I might do it anyway for my own edification and enjoyment (and >>because I think you _will_ be interested at some point in the future ;-).) >> >> > ><laugh> Careful Lee, you almost sound like Bowerbird on that one (but >not quite.) > > The difference is that if I _do_ do it (no promises, as of right now it's just speculation) I will make it publicly available, even in an unfinished state. As a result of the discussions here on the <gloss> tag I can already see that I'm going to have to make changes to my TEI to HTML tables. Hey, it's a work in progress, and I could be wrong (I obviously have been in the recent past ;-)), [snip] >It is also useful for the proposed TEI support in OpenReader. > > Y'eh think? ;-) >>Some months ago I put together a couple of tables showing how HTML could >>be mapped to TEI-lite, and vice-versa. The goal was to create a mapping >>that could be used for round-tripping via XSLT; that is, a TEI-lite >>document could be used to create an HTML document which could then be >>transformed back into TEI without loss of markup. I will probably start >>from those tables in creating a tei.css file. They may also be useful to >>you in creating XSLT scripts (aka XSL style sheets). If you're >>interested they can be found at >>www.passkeysoft.com/~lee/xhtml2tei.html >>and www.passkeysoft.com/~lee/tei2xhtml.html. >> >> > >Well, round-tripping using XSLT and direct rendering of TEI using CSS2 >are two different things. > Absolutely. These kind of tables are useful in developing a CSS file in a different sort of way. If you go out to w3c.org you can find a file that is basically the style sheet for XHTML. If you had a User Agent that knew how to render XML+CSS, but which knew nothing about HTML, you could add this style sheet to an XHTML file and it would render just like in a browser. So if you know that <hi> in TEI maps to <i> in HTML, you could use the same style that <i> uses in the HTML style sheet for the <hi> element in the TEI style sheet. This purely mechanical process isn't going to give you a perfect (or perhaps even adequate) style sheet for TEI, but it will probably get you more than 50% of the way there. [snip] >My view in LIT production is to go from PG-TEI to well-structured >XHTML 1.1 (which is probably what Lee means by "HTML".) > Oh, yeah. If you're going to use XSLT to transform TEI to HTML it makes absolutely no sense to output anything _other_ than XHTML 1.1. To my knowledge there are no tools that rely on structures of HTML 3.2 which are unavailable in XHTML 1.1 (except for the fact that some older browsers need a space before the slash on empty elements, e.g. <hr />). When I say HTML you can always assume I'm talking about XHTML unless I make it explicit otherwise. >Definitely Lee is right in that <p> is not the best for this purpose, >and Marcello is right in that how Lee used it is incorrect. In fact, >the closer I look at the above example, the more it looks like XHTML >definition lists with almost an exact mapping between the two except >that XHTML <dl> (analogous to TEI <list type="gloss">) cannot contain >anything but <dd> <dt> pairs, while the TEI version can also contain a ><head>er. > > This is something that actually bothers me quite a bit about the TEI implementation of lists. As a programmer, I want a definition list (of which a glossary is a specific instance) to be structured in such a way that I can grab _one_ element and get both the term _and_ the associated definition. I really dislike both the HTML and the TEI implementation where it relies on the definition to be in a separate element from the term, but immediately following it. The two elements are obviously inextricably linked, but the vocabularies require the encoder to make the link explicit if it is to exist at all. If I ruled the world, the term and its gloss would be combined into an item element, as follows (example modified from the sample at http://www.tei-c.org/P4X/CO.html#COLI) <list type="gloss"> <head>Unit Three --Vocabulary</head> <item> <term lang="la">acerbus, -a, -um</term> <gloss>bitter, harsh</gloss> </item> <item> <term lang="la">ager, agr&imacr;, M.</term> <gloss>field</gloss> </item> <item> <term lang="la">audi&omacr;, -&imacr;re, -&imacr;v&imacr;, -&imacr;tus</term> <gloss>hear, listen (to)</gloss> </item>  </list> I believe that this implementation of a glossary list would pass the scrutiny of a XML validator, but it is nonetheless incorrect as the TEI spec clearly states that "it is a semantic error for a list tagged with type='gloss' not to have labels." Heck, I dislike the TEI implementation of glossary lists so much that I am tempted to suggest using lists of type "glossary" instead of type "gloss" just to avoid the specification's requirements (which, by the way, an XML validator would not catch. Validators can tell you when you've done something wrong, but not when you've failed to do something right). >In fact, as I look at it, getting the example above to work >in XHTML is problematic because of the <head> line. In fact, XHTML has >pretty poor list support for internal headers and the like (all the >lists: ol, ul, and dl, only support li, and dd/dt for dl), so this >looks like item #6 in my "problems with TEI+CSS2 rendering" list. > > Not so, because the problem is one of mapping between TEI and XHTML, not one of rendering TEI with CSS; although you could certainly add it to your "problems with transforming TEI to XHTML" list. CSS can deal with headers inside of lists without problem, it's HTML that has the problem. >Jon > >

1 0

Re: gutvol-d Digest, Vol 13, Issue 21
by Lee Passey 24 Aug '05

24 Aug '05

Marcello Perathoner <marcello(a)perathoner.de> wrote: > Lee Passey wrote: > >> I understand that creating a file format which could be viewed >> without further processing was not your intention, but now that we >> have some evidence that suggests that it is a real possiblity is >> there any reason _not_ to pursue that possiblity, especially if it >> only requires adding three lines to the source (and making sure that >> all the dtd's are accessible)? > > > Supporting CSS styling will add another complexity layer to an already > overly complex thing. A software architect has to leave things out to > make the design implementable. Adding three lines to the template file adds complexity? > Also, things like footnotes are impossible with CSS. So why bother? I've never had any problems with footnotes and CSS. But the real key is to separate the TEI and the CSS, even at a conceptual level. I would never suggest creating a TEI file with the assumption that it would be rendered in conjunction with some specific CSS file, or indeed assuming that it will have some specific rendering at all. I recommend creating TEI files that are both valid and correct with regard to the TEI spec and not be concerned at all about how it might be rendered. On the other hand, simple modifications which will enable other people and applications to select a rendering should be acceptable if it's not a hinderance to the primary goal of producing valid and correct TEI. >> In any case, it doesn't matter which encoding is used, so long as it >> is not misrepresented in the <?xml ...> declaration. > > > Both the TEI and the XHTML file are correct. I don't know why it > doesn't work for you. I think I may. I downloaded the ZIP archive of the file to be sure that there were no issues involving Apache or Firefox. After extracting the contents, and before touching the file with any other application, I did a hexdump on the file. Sure enough, it was valid UTF-8 encoding. I don't know which of my editors did the conversion, but I suspect it was Microsoft's XML editor which ships as part of of Visual Studio Dot Net. I also suspect that the conversion was not to iso-8859-1 but to win-1252, which is indistinquishable from 8859-1 except in the range of 128-159. The HTML editor that shipped with earlier versions of Visual C++ was known to do this conversion under the covers and without warning. After all, if you're running on a version of Microsoft Windows you're obviously going to want to be using Microsoft's own character mappings, right? >> As part of my CSS experimentation, I set the display setting for the >> <tei-header> element to "none", because while I think the data is >> important, I'm not particularly interested in seeing it when I'm >> reading. When I did this, I thought I lost the title of the book >> because it only appears in the <tei-header> element. I discovered >> later the title was repeated in the <front> element, identified as a >> <head>er. As I read the TEI spec, (and I am by no means well-versed) >> I believe that there should also exist a <titlePage> element which >> should be part of the <front>, and which should contain all the >> information traditionally found on the title page of a book. > > > That is for the encoder to decide. If the title page is interesting > enough to warrant a separate encoding, she will use <titlePage> etc. > to mark it up. Indeed. And as Mr. Hutchinson is the encoder, I'm suggesting he ought to conside it. > If the title page is just plain boring you can generate a standard > title page with <divGen type="titlepage">. This will pull all data out > of the <teiHeader> and save you the trouble. > > There are a lot of such shortcuts implemented like <divGen type="toc"> > and <divGen type="footnotes">. I'm not terribly enamored with <divGen> tags, because it seems to rely on software that so far is largely unimplemented. _I_ wouldn't recommend its use, but it _is_ part of the spec... >> I also note that you encoded the glossary at the end of the work with >> <p> tags (naughty, naughty). Based on what I saw in the TEI docs I >> would have encoded it as follows: >> >> <div type="glossary"> >> <head>Glossary</head> >> <list type="gloss"> >> <label>'Abdu'l-Bahá</label> >> <gloss>The "Servant of Bahá", Abbás Effendi (1844-1921), the eldest >> son and appointed Successor of Bahá'u'lláh, and the Centre of His >> Covenant.</gloss> > > > And it wouldn't have validated because gloss has no business inside list. True. I made the same mistake that Mr. Hutchinson did with the <title> element: assuming that an element designed to indicate usage was instead structural. Mr. Hutchinson's orignal was valid but incorrect (because the textual fragments he was dealing with were not paragraphs). My example was correct but invalid (because <gloss> cannot appear within lists). By encapsulating the <gloss> elements with <item> elements the glossary would become both correct _and_ valid. (My thanks to Mr. Noring for posting the links to the relevant portions of the spec so I don't have to.)

2 1

Re: prank someone is pulling
by Gutenberg9443＠aol.com 24 Aug '05

24 Aug '05

TO ALL: Someone purporting to be from PG has faxed a book, in Finnish, the name of which is "Fredrika Runeberg," to the state of New Jersey Surveying Office. Whoever did it somehow managed to get around the requirement that the sender's name and telephone number is to be on the first page of all faxes. I have assured him that nobody in our organization did it. He wanted to fax the first page to me but my fax is down right now, and I wanted him to mail it as an attached file but he doesn't have a scanner. Therefore, he has lost the 33 sheets of paper that were in his fax machine and is afraid to try to reuse the fax machine because it will immediately try to go on printing. (I told him to turn it off, unplug it, then replug it and turn it on, and he would probably then be able to use the fax machine normally.) He didn't give me his name other than "Jim." I have his telephone number but will release it only to Greg. I have asked him to snail mail me the first page and let me see what I can find out. If anybody on this ML is the culprit, cease and desist and notify me personally that you did it. Then I will only bite your head off, spit it into your face, and then turn it over to Greg. If anybody on this ML is the culprit and does not admit it and gets caught, that person's ass is grass and that person will be permanently barred from this ML and everything else I can get him barred from. This conduct is unconscionable. Anne Do you like to breathe? Then save the trees! Begin a personal relationship with an ebook TODAY!

1 0

the new mantra for project gutenberg
by Bowerbird＠aol.com 24 Aug '05

24 Aug '05

marcello said: > I don't know why it doesn't work for you. this will increasingly become the mantra for project gutenberg... -bowerbird

2 1

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol 13, Issue 20)
by Lee Passey 23 Aug '05

23 Aug '05

Marcello Perathoner <marcello(a)perathoner.de> wrote: > Lee Passey wrote: > >> It appears that the file is latin-1 encoded, despite the fact that >> the DTD claims that it is utf-8 encoded. This caused Firefox some >> grief as it tried to utf-8-decode some latin-1 accented vowels. > > > That is just what Apache thinks it is because it doesn't look inside > the file before serving it. Apache can be made to serve the encoding > based on the file extension. Lacking a definite extension it will > serve the default which is iso-8859-1. In this case I saved the file to my local file system before doing anything with it. Are you suggesting that Apache (your server) looked at the contents of the file it was serving and replace the <?xml ...> declaration to "<?xml version="1.0" encoding="utf-8" ?>" before serving it? Or are you suggesting that as it transfered the file it changed utf-8 encoded characters to Latin-1 encoding? (I've never seen that behavior in Apache before, but I could have overlooked something.) If I retrieved the file via FTP would it be different than if I retrieved it using HTTP? >> I grabbed an arbitrary "tei.css" style sheet off the net, and added >> the line: >> >> <?xml-stylesheet href="tei.css" type="text/css"?> > > > You can also include an XSL stylesheet which gives you far more power. XSL isn't really a stylesheet, it is a scripting language for a transformational engine. XSL has many good uses, but applying styles to a document isn't one of them. Indeed, I've never figured out how to use XSL to style an XML file without having an existing Cascading Style Sheet that I could use for the actual styles. > But why do you want to look at the TEI file in the browser when there > is an HTML file available? Why ask why? Actually, I'm not interested in looking at the file at all; it's as boring as hell. What I _am_ interested in is exploring the use of TEI as an archive format, _and_ as a content delivery format. I think that enabling a TEI-XML file to be used by a browser directly, if it can be done without compromising its function as an archive format, is a worthwhile goal, and in many cases better than requiring some sort of XSL transformation before it can be viewed.

4 4

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives!
by Joshua Hutchinson 23 Aug '05

23 Aug '05

----- Original Message ----- From: "Kevin Handy" <kth(a)srv.net> > Any plans on making something like guiguts for pgtei, and > bundling all the conversion routines with it? Not by me personally, but when I turn DP loose on this format, I expect a flurry of tools to follow. :) As an aside, I do all my editing for my TEI files in GuiGuts right now. My only annoyance right now is that I wish it didn't add the darned Byte Order Mark to the beginning of the file when it detects UTF-8 characters. Josh

1 0

re: [gutvol-d] the issues with using stylesheets across many documents
by Bowerbird＠aol.com 23 Aug '05

23 Aug '05

marcello said: > No, there is not. marcello, _you_ might not have any large-scale stylesheet experience. but perhaps someone else here has. if not, then it will be a very bumpy ride over the next few years, as y'all learn. > We are all new into this. um, well, speak for yourself. i started using stylesheets back in 1987, with the first release of ventura publisher. and i figure i made the 428 common mistakes most people make, and learned to avoid 'em... > We want to get there and we will learn as we go. and again, i'm guessing that someone here has already been there, and back, and will guide you, if you let them. there are a lot of people on this listserve, willing to help... > Software development is an iterative business. and again, someone has already done that back-and-forth. > Many problems surface as you > start using the first implementation. stylesheets are well past their "first implementation". > With what you learn from the first implementation > you go back and do the second. And so on. stylesheets are well past their "second implementation". > Requiring all problems to be known > and solved in advance is the one sure fire thing > to never get started. Known as: "analysis paralysis". and ignoring the lessons of the past is one sure-fire way to repeat the pain... now, is anyone willing to step in and help out project gutenberg? please? thank you... -bowerbird

1 0

the issues with using stylesheets across many documents
by Bowerbird＠aol.com 23 Aug '05

23 Aug '05

i'd like to assure myself that there is experience here on the issues with using stylesheets across many documents. how would you sum up _the_major_question_, and answer it? what problems typically arise? what are some workarounds? when/how/why do workarounds cause their own problems? anyone who has worked extensively with stylesheets knows their magical power is typically matched by an ornery ability to mess things up too, and very badly. is that expertise here? please, someone, show me that it is, with a detailed treatment. (or else i will have to come in and give one, and you all know how insufferable my superior tone can be, right?). thank you. -bowerbird

2 1

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives!
by Lee Passey 23 Aug '05

23 Aug '05

Joshua Hutchinson <joshua(a)hutchinson.net> wrote: > Thanks to some back and forth with David Widger, we have posted a text > to the PG archives that is basically the XML with its straight from > conversion txt, html and pdf files. > > http://www.gutenberg.org/1/6/5/2/16523 > > For those interested: This book (Kitab-i-Aqdas) is a religious book > from the Baha'i Faith. The text is freely available from the Baha'i > website with a usage license that allows us to post the text to our > archive as long as we don't make any content changes. I've basically > converted it from the Microsoft Word format they posted in to a PGTEI > based master and used that to create text in UTF-8, Latin-1 and 7-bit > ASCII, html and pdf. > > Regarding the XML. The XML file can be found in the 16523-x > subdirectory. These files are not designed to be read directly in a > web browser like IE or Firefox. They are plain text files and open > just fine in Notepad or vi or any other text editor of choice. For > those wishing to play with the XML, our online validator and > conversion tools can be found here: > > http://www.gutenberg.org/tei > > Besides wanting to celebrate the first XML posting ;) ... I'm also > looking for contructive criticism. What doesn't look right? What > problems do you see with the results? Congratulations on a worthwhile accomplishment. I would like to point out, however, that this is _not_ Gutenberg's first XML posting; I believe there are hundreds of XHTML files currently available. You probably intended to say that this is Gutenberg's first TEI-XML posting. I know that this seems like picking at some pretty minor nits, but there are some people who believe that there is actually a text markup language called XML. XML is actually a syntax for creating markup languages, and there are many markup language available which conform to the XML syntax, e.g. XHTML, TEI, and DocBook. For clarity's sake it is probably desirable to always refer to a specific XML vocabulary, except when discussing the XML syntax which applies to all XML vocabularies equally. Some specific, and very preliminary observations: As Mr. Noring is always quick to point out, XML files can be viewed natively in both Firefox and IE6 when accompanied by appropriate style sheets, so I attempted to open this file directly in both of these browsers. In IE6, I get the error "The system cannot locate the object specified. Error processing resource 'http://www.tei-c.org/P4X/DTD/pgtei-extensions.ent'. Apparently, your dtd, http://www.gutenberg.org/tei/marcello/0.3/dtd/pgtei.dtd, contains the line: <!ENTITY % TEI SYSTEM "http://www.tei-c.org/P4X/DTD/tei2.dtd"> %TEI; It looks like IE sees a full url for the TEI SYSTEM entity, so it assumes that <!ENTITY % TEI.extensions.ent SYSTEM "pgtei-extensions.ent" > refers to a file on the same system as "tei2.dtd." Of course, the TEI consortium doesn't maintain a file called "pgtei-extensions.ent", so IE fails catastrophically. Now I'm still having a hard time wrapping my head around dtd's, so I have no idea if IE's behavior is technically correct or not, but it would be nice if the dtd's could be reworked in such a way that this failure does not occur, perhaps by hosting the TEI dtd's at http://www.gutenberg.org/tei/marcello/0.3/dtd/, and referencing them there. Firefox does not have this problem, but Firefox also breaks when it encounters named entities, even when the entities are referenced in .ent files included from the dtd's, leading me to believe that Firefox avoids the problems associated with "roaming dtd's" by simply not parsing them in the first place. Numerical entities _are_ recognized, and rendered appropriately, as are named entities when the entity definition is contained in the XML file itself. I have no solution to this problem, except to suggest that named entities simply be avoided in favor of numeric entities, at least in the short term (I do note that the etext 16523-x.xml does not contain any named entities). One of my pet peeves is the use of the <p> (paragraph) tag as a generic block tag, rather than limiting its use to true paragraphs, and using the <div> tag for generic blocks of text. I am happy to say that the text is mostly correct in this regard. The byline <p>by Bahá’u’lláh</p> should be marked using the <byline> tag instead of <p>; there may be other similar problems I simply haven't encountered yet. It appears that the file is latin-1 encoded, despite the fact that the DTD claims that it is utf-8 encoded. This caused Firefox some grief as it tried to utf-8-decode some latin-1 accented vowels. I grabbed an arbitrary "tei.css" style sheet off the net, and added the line: <?xml-stylesheet href="tei.css" type="text/css"?> to the beginning of the file. Looking at it in both browsers (after I had copied enough .dtd's and .ent's to my local file system that IE could cope) the document looked quirky, but readable. When I deleted the .css file the document turned into a plain-text file, totally without styling, but nothing broke. I think every PGTEI document should probably start with the three lines: <?xml-stylesheet href="tei.css" type="text/css"?> <?xml-stylesheet href="pgtei.css" type="text/css"?> <?xml-stylesheet href="usertei.css" type="text/css"?> and one of the next tasks should be to develop CSS files for generic TEI files and PG TEI files (the "usertei.css" file should be reserved for sophisticated users who may want to override the standard styles). If this were done (and the dtd issues are resolved for IE), the production TEI files should be usable directly by a modern web browser without any kind of pre-processing. If you're interested, I'll start putting together a generic CSS file for TEI.

5 5