- gutvol-d - lists.pglaf.org

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol
by Joshua Hutchinson 24 Aug '05

24 Aug '05

Dave, we're talking about TEI/XML. Nothing of what you said applies here (but you would be absolutely right on a HTML document, as I understand it). ;) Josh ----- Original Message ----- From: "David A. Desrosiers" <hacker(a)gnu-designs.com> To: "Project Gutenberg Volunteer Discussion" <gutvol-d(a)lists.pglaf.org> Subject: Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol Date: Wed, 24 Aug 2005 15:49:24 -0400 (EDT) > > > > I've learned the fear the <div> container. Let me show you why using a > > <div> container for "non-specific" blocks of text won't work. > > > <div> > > <head>Level 1</head> > > <p>Paragraph 1.</p> > > > > <div>Block o' text.</div> > > > > <p> Paragraph 2.</p> > > > > </div> > > Improperly nested tags will never validate. You can't have a bare string > inside the <head> tag like that, and <head> isn't a child of <div>, so that > won't work either. After correcting those errors, it validates fine. > > > The above will not validate. Once you go one deeper in a nest, you cannot > > come back up just one level. You have to close the whole nesting. > > Nope, this is completely untrue. > > > The above would work if changed to: > > > > <div> > > <head>Level 1</head> > > <p>Paragraph 1.</p> > > > > <div>Block o' text.</div> > > </div> > > > > <div> > > > > <p> Paragraph 2.</p> > > > > </div> > > You're still producing invalid markup. Try something like this: > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> > > <head><title>Level 1</title></head> > <body> > <p>Level 1</p> > <div> > > <p>Paragraph 1.</p> > > <div>Block o' text.</div> > > <p> Paragraph 2.</p> > > </div> > </body> > </html> > > > David A. Desrosiers > desrod(a)gnu-designs.com > http://gnu-designs.com > _______________________________________________ > gutvol-d mailing list > gutvol-d(a)lists.pglaf.org > http://lists.pglaf.org/listinfo.cgi/gutvol-d

2 1

Re: [gutvol-d] Re: prank someone is pulling
by Gutenberg9443＠aol.com 24 Aug '05

24 Aug '05

In a message dated 8/24/2005 10:36:42 AM Mountain Daylight Time, joshua(a)hutchinson.net writes: It is doubtful anyone that has anything to do with PG had anything to do with this. I agree. I told him that anybody in the world, anywhere in the world, can download our files and then use them in this way. I suspect he has annoyed someone who is using this means of revenge. Anne Do you like to breathe? Then save the trees! Begin a personal relationship with an ebook TODAY!

1 0

Re: [gutvol-d] Re: prank someone is pulling
by Joshua Hutchinson 24 Aug '05

24 Aug '05

Ann, this is called a FAX bomb. It is similar to a "e-mail bomb" where someone drops a bunch of e-mail garbage on someone to clog their e-mail account. It is usually someone who wants to "get back" at someone else. FAX bombs are especially nasty because then you are not only tying up their service, you are wasting tangible resources like paper and ink. The reason our file is being used is probably pretty simple ... we have great big text files that are easily accessible and work perfectly for this kind of griefing. It is doubtful anyone that has anything to do with PG had anything to do with this. Josh ----- Original Message ----- From: Gutenberg9443(a)aol.com To: gutvol-d(a)lists.pglaf.org, gbnewby(a)pglaf.org Subject: [gutvol-d] Re: prank someone is pulling Date: Wed, 24 Aug 2005 12:14:26 EDT > > 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! > > > _______________________________________________ > gutvol-d mailing list > gutvol-d(a)lists.pglaf.org > http://lists.pglaf.org/listinfo.cgi/gutvol-d

2 1

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