- gutvol-d - lists.pglaf.org

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

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

22 Oct '04

marcello said: > That may not be simple but is still better than what you have now: > if the txt file happens to lack the page numbers > there is no way you could get them short of redoing the book. you wouldn't need to "redo the book" to insert page number information. and if the .html file had that information, you could do it automatically. and if page-number information _was_ included in the text-file, i would support it in my viewer-program. so tony, or any other user, could simply toggle its display on or off, by choosing a menu-item. it's ridiculous to have users go through all the difficulty of doing a conversion to access such a simple and basic piece of information. y'all should step back and look at yourselves for even suggesting it. and why should the text-file "happen to lack the page numbers" in the first place? that kind of terminology makes it sound so "accidental". distributed proofreaders retains page-number information through all of its processes, because, get this, they find it's useful to them. but then they drop it from the final product! why? don't they realize that someone else might find it useful? of course they do, that's why people have started _retaining_ it (i almost said "including" it, but that's the same type of error) in the .html versions. but nonetheless, it is still dropped from the text-file. just like the information about the names of image-files and their correct placement. it's as if there was a conscious attempt to make the text-files as useless as possible. and what will the users at large think when they are informed that this policy is in place? i don't know for sure, but i'm gonna find out. -bowerbird

2 1

re: Re: [gutvol-d] aspects of a well-done e-book
by Joshua Hutchinson 22 Oct '04

22 Oct '04

----- Original Message ----- From: Bowerbird(a)aol.com > > holden said: > > So, whereas before, you had to have the standard TXT or HTML versions > > because that was all that was available, now we can actually talk about > > making customised versions as people want them. > > so every time a person wants to switch an option, > they have to go and do the conversion over again? > > do you really not see why that won't appeal to them? > As opposed to not having an option at all, like we have now? So, they can either have exactly what they have now... or if the want to, they can have more with a little extra effort. You're right, we shouldn't give them anything new. Oh, and don't tell me the reader program should do it. The reader program will never be the same for every reader, even if you do actually produce a working program. The only way to provide this information that is platform/reader program independent is to somehow put that into the source in a standard format that multiple reader programs will support. So far, XML is the *only* format anyone has suggested that will allow that. Josh

1 0