October 2004 - gutvol-d - lists.pglaf.org

re: re: Re: [gutvol-d] re: coming to michael doorstep with hat in hand
by Bowerbird＠aol.com 22 Oct '04

22 Oct '04

the hacker said: > I said no such thing it's silly to argue about this. this is what you said: > For the users who refuse to learn, to adapt, and to grow, > they can stagnate and stay in their own nice warm puddle. you also said this: > if my code works in 13 browsers, and fails in MSIE, > my code is not the problem. I do, however, > refuse to add "hacks" to get MSIE to do what > it should be doing anyway... following the standards. those aren't the types of things michael hart would say. there's no reason to get all up in a huff. i'm not telling you that you need to change. on most days, i share your feelings. and i have said often that every e-book-related innovation will come sniffing for a chance to work with this library, and needs to prove its ability to handle it to earn its stripes. so i'm not faulting you for being here. that's why i'm here. but what you've said here is _not_ what michael would say. so the simple fact is that yours is _not_ the attitude that has guided project gutenberg from where it started to today. the mission here has been to do _whatever_it_might_take_ for those e-texts to be available to the maximum audience. among the many things that that has meant is to work with the _trailing_ edge, not the _leading_ edge, of technology. and that strategy hasn't caused it to "stagnate", but rather what has caused it to grow into the biggest cyber-library... -bowerbird

5 6

Re: [gutvol-d] barriers to XML posting
by Joshua Hutchinson 22 Oct '04

22 Oct '04

Excellent! Your answers are exactly what I was hoping they would be! (Does this mean I'm starting get my brain wrap around this stuff? ;) ) I think the next step(s) should be making some XML, running in through the transforms, critiqing the output and improve the transform/CSS until we have a workable process, yes? I'll try to take a look at some of the XML you and Joeren have done up to this point and see what the transform on the server does with them. We've already identified a need for a "standard" title page format, so that'll be my first area I'll look at. Josh ----- Original Message ----- From: Marcello Perathoner <marcello(a)perathoner.de> To: Project Gutenberg Volunteer Discussion <gutvol-d(a)lists.pglaf.org> Subject: Re: [gutvol-d] barriers to XML posting Date: Fri, 22 Oct 2004 20:05:45 +0200 > > Joshua Hutchinson wrote: > > > Shouldn't a TEI-Lite validator flag your second example as wrong, > > too? Looking over the TEI-Lite documentation, you could markup that > > information, but in a slightly different format. > > That was just a general example. It was not meant to be specific to TEI. > > > Now, putting aside the fact that I doubt I'd ever bother to mark up > > an address to that exacting of a detail ;) ... Am I understanding the > > role of the validator properly in that it should choke on the first, > > since it doesn't, as far as I can tell, conform to TEI-Lite? > > It will choke if you validate my example against the TEI DTD. But I > could write a SOMETHING DTD that validates that example all right. > > > That seems acceptable to me. For instance, to continue you example > > above, if you wanted to add <place>, <name>, and <street> to the > > <address> markup, then you could put those elements in your > > personally DTD, which calls the TEI-Lite DTD, and then the validator > > should be able to parse it as acceptable code, right? > > Yes. > > > But the question then becomes, will the standard transform be able to > > handle the new code in your DTD? If it just ignores what it doesn't > > understand, that would be acceptable, I'd think. But if the new tags > > cause the transform to choke, then we'd have a problem. > > A standard TEI transform will simply ignore all tags he doesn't > recognize. Just like a HTML browser does. > > > > -- > Marcello Perathoner > webmaster(a)gutenberg.org > > _______________________________________________ > gutvol-d mailing list > gutvol-d(a)lists.pglaf.org > http://lists.pglaf.org/listinfo.cgi/gutvol-d >

1 0

Re: [gutvol-d] barriers to XML posting
by Joshua Hutchinson 22 Oct '04

22 Oct '04

----- Original Message ----- From: Marcello Perathoner <marcello(a)perathoner.de> > > Joshua Hutchinson wrote: > > > Hmm... Maybe I misunderstand here. If a file comes in, marked up in > > TEI-Lite and we cannot transform it with our standard process, it > > seems to me either the DTD we've chosen is incomplete or the TEI > > markup has a bug. > > Consider following examples. > > A DTD-based validator can catch this: > > <address> > <date>01 Jan 2004</date> > </address> > > because a date has no business inside an address. > > But not this: > > <address> > <name>Chicago</name> > <street>2830 North Clark</street> > <place>Curl Up and Dye Beauty Salon</place> > </address> > > The validator cannot know that the markup is all wrong. Of course this > will _transform_ all right. > > Ok, I am learning here, honest. But here's another dumb question in the meantime. Shouldn't a TEI-Lite validator flag your second example as wrong, too? Looking over the TEI-Lite documentation, you could markup that information, but in a slightly different format. <address> <addrLine><name type="city">Chicago</name></addrLine> <addrLine><name type="street">2830 North Clark</name></addrLine> <addrLine><name type="place">Curl Up and Dye Beauty Salon</name></addrLine> <address> Now, putting aside the fact that I doubt I'd ever bother to mark up an address to that exacting of a detail ;) ... Am I understanding the role of the validator properly in that it should choke on the first, since it doesn't, as far as I can tell, conform to TEI-Lite? > No. All you can define inside an XML file is the DTD (or other schema) > you want to use and entities like &myentity; > > Of course you can use a DTD that defines some stuff and then includes > the standard TEI DTD. But, as said above, there is a better way to do > that in TEI. That seems acceptable to me. For instance, to continue you example above, if you wanted to add <place>, <name>, and <street> to the <address> markup, then you could put those elements in your personally DTD, which calls the TEI-Lite DTD, and then the validator should be able to parse it as acceptable code, right? But the question then becomes, will the standard transform be able to handle the new code in your DTD? If it just ignores what it doesn't understand, that would be acceptable, I'd think. But if the new tags cause the transform to choke, then we'd have a problem. Josh

2 1

re: re: Re: [gutvol-d] aspects of a well-done e-book
by Bowerbird＠aol.com 22 Oct '04

22 Oct '04

ingram said: > One of the advantages of using > a standard, structured, and well-supported format > for marking our texts is that we can do things with them > that you don't see the utility of. if users want something, i'll provide it, even if i _cannot_ see the utility of it... but perhaps _you_ can explain to me the utility of showing page-numbers and nothing else? because, for the _life_ of me, it escapes me right now. i've only thought about it for 5 minutes, and maybe something will come to me just as soon as i hit "send" on this, but... -bowerbird

2 1

re: Re: [gutvol-d] aspects of a well-done e-book
by Bowerbird＠aol.com 22 Oct '04

22 Oct '04

marcello said: > Assiming a worm has eaten himself > thru a fat and juicy word in a book. > How do you mark that up in ZML ? with an annotation. or with a form of emphasis you'd label as "wormhole". (how is this _currently_ indicated in the e-texts? oh, never mind, don't answer that, nobody cares...) besides, this is the kind of question you should be asking on the beta-test listserve for the z.m.l. viewer-program... people on _this_ list don't need to read about the simple implementational details of z.m.l., they just need to know that it's a good way to escape from the complexity of x.m.l. markup, a way that gives powerful e-book functionality, and yet still resonates with the plain-text files they are familiar with from project gutenberg... -bowerbird

1 0

Re: [gutvol-d] Re: barriers to XML posting
by D. Starner 22 Oct '04

22 Oct '04

Steve Thomas writes: > Is it possible to OCR a scan directly to XML? Or is the output > from OCR always going to be text? We don't usually scan to text; we scan to RTF, and guiprep extracts some of the markup and converts it to lightly marked up text. guiprep could certainly convert the RTF to XML if we wanted, but DP plans to seperate the markup and proofing rounds. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

re: re: Re: [gutvol-d] aspects of a well-done e-book
by Bowerbird＠aol.com 22 Oct '04

22 Oct '04

joshua said: > As opposed to not having an option at all, like we have now? except there's a _much_ easier way to give them the option. it's the same way you do it with .html -- put it into the file in a way that enables them to turn it on and off as they wish. if you're not imaginative enough to figure out how to do that, then just sit on your hands until you see how i accomplish it. if you ain't gonna put the information in the file, no viewer on the surface of the planet can put it in. but that's _your_ fault, not the fault of the program. and it shows you don't have the user's interest at heart. > Oh, and don't tell me the reader program should do it. telling _you_ is an exercise in futility. but when i tell other people that a reader-program should do it, and give them one which actually does it, _they_ will understand. and then _they_ will start telling you to include that information. i've tried speaking to "the powers that be" directly, and found them nonresponsive, so i'll route stuff through the _users_ from now on. -bowerbird

3 2

re: Re: [gutvol-d] Re: barriers to XML posting
by Bowerbird＠aol.com 22 Oct '04

22 Oct '04

marcello said: > Bumbling along without a clue, as usual? your process is _fragile_. and everybody can see that. the person who would be the emperor's tailor is naked. -bowerbird

1 0

re: Re: [gutvol-d] aspects of a well-done e-book
by Bowerbird＠aol.com 22 Oct '04

22 Oct '04

marcello said: > You are being narrow-minded about this. that's an _incredibly_ stupid thing to say. > What if the user wanted to see *only* the page numbers. > Your reader does not support that. well, my program doesn't support original-page-numbers _at_all_ yet, we're talking about what i _will_ implement, so i don't see how you can assert anything on the matter. i'm not sure i understand the request, anyway -- you want to see _only_ the page numbers, nothing else?, i don't see any utility in that, you would have to explain it, but since the user can control the color of the text, they'd just match it to the background color to make it "disappear" -- but if it is something that readers will want, i _will_ support it. -bowerbird

2 1

re: Re: [gutvol-d] Re: barriers to XML posting
by Bowerbird＠aol.com 22 Oct '04

22 Oct '04

marcello said: > But this is sooo tedious! We have to replicate the exact setup of > gutenberg.org *and* pglaf.org to get reliable results from the beta-test. > Example: my servers are all debian and have perl 5.8 > whereas ibiblio is redhat enterprise with perl 5.6. > This has often before given me headache because > programs that ran at home, misteriously failed at ibiblio. if it can't even span 2 versions of linux which run perl that is .2 versions apart, that means the process is very fragile; not nearly as robust as x.m.l. advocates always make it sound in their sales pitch. -bowerbird

2 1