dm-l April 2005

dm-l@uleth.ca

16 participants
25 discussions

Choosing an XML Editor
by James Cummings 12 Apr '05

12 Apr '05

Dear DM-L Some readers may be interested in an AHDS information paper that we have recently released. It was written by Thijs van den Broek as part of his technical report on the possibilities of Benchmarking XML-editors. http://ahds.ac.uk/creating/information-papers/xml-editors/ It is a highly subjective report and really concerns the perceived usability of the editors by different groups of people. My preferred editors are tei-emacs and oXygen, by the way. -James -- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at oucs dot ox dot ac dot uk

5 7

Question about CSS and IE
by Daniel O'Donnell 11 Apr '05

11 Apr '05

Hi all, I have a question about Internet Explorer. We are proofing the journal right now, and have discovered that IE doesn't seem to display quotation marks for the html:q tag. To indicate italics, we follow the W3C recommendation and use <q> rather than marks to rend quotations, article titles, and the like. In our CSS, we indicate how those marks are supposed to appear (e.g. when nested). In this specific case, we have --In HTML-- <q>quoted text</q> --In CSS-- q { quotes: “ ” } q q { quotes: ‘ ’ } q q q { quotes: “ ” } q:lang(FRA), q:lang(ITA) { quotes:« »; } (we've also tried: q { quotes: '"' '"' } q q { quotes: "'" "'" } q q q { quotes: '"' '"'; } q:lang(FRA), q:lang(ITA) { quotes:« »; } ) Weirdly, the Italian and French quotes work fine in all browsers; the other q styles work in Opera and Firefox. Any suggestions? -dan -- Daniel Paul O'Donnell, PhD Associate Professor of English University of Lethbridge Lethbridge AB T1K 3M4 Tel. (403) 329-2377 Fax. (403) 382-7191 E-mail <daniel.odonnell(a)uleth.ca> Home Page <http://people.uleth.ca/~daniel.odonnell/> The Digital Medievalist Project: <http://www.digitalmedievalist.org/>

2 1

RE: [dm-l] what xslt can't do..?
by Binkley, Peter 11 Apr '05

11 Apr '05

(With apologies to the list for not trimming quoted messages in this exchange). I've just about run out of things I wanted to say on this, but I wanted to respond to a couple of points in Peter R.'s last posting. I've learned a lot from this exchange and thank all Peters and others who have participated, in particular Peter R. for his patient and thoughtful responses. Peter R. wrote: > Still, this is quite a difference from the 'generate static > files to optimize particular views' approach (actually, the > cocoon example Peter B gives seems to be such, and so not > really comparable to what A does). That is indeed what I intended, and I do see it as comparable to Anastasia: a relatively slow and complex pre-processing of the source XML to enable a relatively fast and simple front-end. Whether the pre-processing involves indexing as Anastasia does or chunking and transforming as the theoretical Cocoon-based system would do, doesn't seem to me to be material. They both have to be done, and redone every time the source changes. And I admit that A's pre-processing will be much, much faster than the kind of system I'm imagining. > Under that, you have to figure out in advance just what > particular views you want to enable. And, there can be a > near infinite number of these. But once we're dealing with XML files containing a single page's worth of XML, XSL is back on its home turf, using Xpath to deal with complex parsing of the XML source. Even if the pre-processing did nothing but chunk the TEI into pages, the stylesheet to extract the text of a given witness would be fairly simple. As one of my first XSL projects I hacked a Cocoon-based system to present critical editions for a text I was working on; the underlying format isn't TEI (I didn't know any better at the time and was working with texts I originally transcribed in Nota Bene) and the XSL is far from optimal or bug-free, but it at least shows that this can be done. The prototype is here: http://www.library.ualberta.ca:8080/cocoon/quentin/sp-0prol.html . The number of witnesses is nowhere near 50, but there's rather more than a page of text here (about 70k of xml). Set your options in the menu and click the "Render" button: you can select a base witness, compare two witnesses in parallel columns with differences highlighted, or generate an app. crit. containing variants from selected witnesses. A text with about 50 hexameters and 26 witnesses is here: http://www.library.ualberta.ca:8080/cocoon/quentin/decmet-page.html , about 140k of xml (unfortunately, I apparently never finished adapting the stylesheet for my clumsy verse format, so the app. crit. isn't coming out right - must get around to fixing that). This is still way too slow, but there's lots I know now that I didn't when I last worked on it, and I'm sure I could improve it. Whether the response time would ever approach Anastasia's for complex texts I don't know, but I wouldn't rule it out without trying. (Now, shall we discuss whether Cocoon's XSL-FO support could ever generate a pdf of a critical edition to compare with XeTeX's output ...) <...snip...> > Another problem is the > process chain itself. If your approach means daisychaining > various processes together, and at the end you discover > something wrong, fixing can be a real pain: you have to go > back, figure out which bit of the chain caused the problem > (which can be real hard, when you have complex interactions) > then rerun the whole thing before you can view the result. > With Anastasia the problem is either in the tcl scripts (in > which case, you can fix and see the results instantly) or in > the source xml (which will mean you need to reindex): there > is no somewhere-in-between. Here we're dealing with personal preferences, I think. I find Cocoon's pipeline structure very handy for debugging, since it's easy to inspect the output of every stage of the process: just add label attributes to the pipeline, and then pass those labels on the query string in a field called "cocoon-view". In the prototype mentioned above, you can add "cocoon-view=source", or "step1", or "step2" to the query string to see the source xml or the output of the two intermediate transformations. This is so easy that I often start off by breaking a process into more transformations than is necessary, until I've debugged it. In debugging a TCL script doing the same complex work, you'd presumably set breakpoints to do the same thing. Peter Baker has summed up the lessons I've drawn from this thread very well. My motivation for defending XSL in such tedious detail is that it is my pet technology, which I freely admit is not always a good ground for choosing. But it shouldn't be dismissed out of hand: the main limiting factor on what we can do, at least in my environment, is not processing power or storage space but my development time. XSL is so useful for so many things that I expect I'll get a higher return on the time I invest if I find a way to do things with XSL than if I try to learn a new technology, even if XSL isn't the best possible tool. I'm also, I suspect, operating from different assumptions about what is "good enough" than Peter R. is, since I'm interested in Latin texts, where the range of orthographic variation is much narrower (and less interesting) than in the vernacular texts that Anastasia has been used on. It may well be that an XSL-based system could get an acceptable level of performance for a Latin text that it couldn't match for a vernacular text of comparable length and number of witnesses. My conclusion: I think a system comparable to Anastasia could be built using XSL; if such a system existed, I'd use it in preference to Anastasia because it would fit better with my technology environment; but now that something as good as Anastasia exists and is available under an open-source license, the only real reason to develop such a system would be for the fun of it. Peter Peter Binkley, Ph.D., MLIS Digital Initiatives Technology Librarian Information Technology Services 4-30 Cameron Library University of Alberta Libraries Edmonton, Alberta Canada T6G 2J8 Phone: (780) 492-3743 Fax: (780) 492-9243 e-mail: peter.binkley(a)ualberta.ca

1 0

RE: [dm-l] what xslt can't do..?
by Peter Robinson 11 Apr '05

11 Apr '05

Peter B(i) is right about how Anastasia does its magic: it does indeed pre-index the xml into various binaries, and it is the information extracted from the xml and so indexed which allows it to perform optimally on such situations. This does mean it is *not* the tool to use if your data is changing frequently. The indexer is pretty fast (about 10 minutes to operate over a 55 mb source collection), and it can be (and has been) automated to run each time files change, though we usually don't operate it so. But I would not use it for (say) a dynamic content management system. Still, this is quite a difference from the 'generate static files to optimize particular views' approach (actually, the cocoon example Peter B gives seems to be such, and so not really comparable to what A does). Under that, you have to figure out in advance just what particular views you want to enable. And, there can be a near infinite number of these. Some bits of our publications do things like: let the reader decide just which out of 50+ manuscripts he wants to see information for (and so, factorial 50 + combinations, already a number so big it is stars in the sky stuff.) And let him or her do this for *every* word of the text -- some 5000 words in our recent publications. Another problem is the process chain itself. If your approach means daisychaining various processes together, and at the end you discover something wrong, fixing can be a real pain: you have to go back, figure out which bit of the chain caused the problem (which can be real hard, when you have complex interactions) then rerun the whole thing before you can view the result. With Anastasia the problem is either in the tcl scripts (in which case, you can fix and see the results instantly) or in the source xml (which will mean you need to reindex): there is no somewhere-in-between. If you want to see a nice instance of Anastasia, not done by us, look at the Laures rare book database (Tokyo) on http://133.12.23.145:8000/html/. Really nifty, I think, is the way this does searches on various names and places etc: choose 'place name' from the search drop down menu and type in Kyoto: you get all kinds of different forms of the name back. Also very nice is the Welsh Biography Online site at: http://yba.llgc.org.uk/ -- this allows you to see the pages formatted as they are in the print by page and column. All the best Peter ---------------------------------- I confess I haven't tried Anastasia yet, through lack of time and not of interest. Glancing at the documentation, I see that Anastasia appears to do lookups in a book file, which has (previously?) been compiled from the TEI. ("This must be an Anastasia book compiled from the XML using the Anastasia GroveMaker tool. This is designed to permit fast, real-time access to any part of the underlying XML.") Anastasia's speed is attributed to the fact that it is "interrogating not the source XML but a set of binary files (an "AnaGrove") which are optimized to permit the fastest access to information about every aspect of the source XML." GroveMaker is written in C. It would appear, then, that Anastasia would have the same syncronization requirements as the kind of pre-transformed XSL-based solution that James is talking about: if you change the TEI, you've got to remember to recompile the AnaGrove. If I've understood this correctly, then it seems to me that the correct object of comparison for Anastasia's ability to present an arbitrary page would not be a single-pass XSL against a large TEI file, but rather, say, a Cocoon pipeline using XSL to present arbitrary XML page files which have been pre-extracted from the TEI file and optimized for presentation by an XSL process along the lines of the one I hacked. The TCL scripts that Peter R. sent would be the equivalent of the matcher and generator in the Cocoon pipeline: <map:match pattern="*/*.html"> <map:generate src="path-to-texts/{1}/{2}.xml"/> ... </map:match> (where a url like "hengwrt/23.html" would be mapped to an extracted page file "path-to-texts/hengwrt/23.xml"). The output of this generator, as of the TCL scripts, is the marked-up text of a given page, ready to be styled and presented to the reader. Anastasia may well still win on speed, of course, if not in the presentation then in the preprocessing. An XSL-based extraction process will have a hard time keeping up with a custom-written C indexer. But it will be a lot easier to maintain, I submit (with apologies if I've misunderstood what Anastasia is doing). Has anyone looked at teiPublisher yet, by the way? (http://teipublisher.sourceforge.net/docs/index.php) Judging from the texts in the "Documenting the American South" project, they seem to have sidestepped the whole problem of presenting arbitrary pages, by only offering the complete text in a single HTML file. I haven't looked into it to see if there are other options, though. Final note regarding the sample text: again, I don't understand what the problem is with the last page, even with the appendix. How can any process know that that last div is an appendix and not a new section of the main text, beginning and ending on page 5? Whatever marker GroveMaker uses to make this distinction would also be available to XSL, presumably. (Perhaps my ignorance of TEI is showing...) Peter Binkley

2 1

Kalamazoo and Leeds Conference programmes on DM Wiki
by Daniel O'Donnell 10 Apr '05

10 Apr '05

Hello all, We are in the process of revamping the DM Wiki. As part of this, I thought it might be good to start an annual conference program for digital topics at Kalamazoo, Leeds, and elsewhere. I've started the Kalamazoo program, by listing the DM topics and the one talk in a general session that I know of. If you are giving a paper or organising a session at Kalamazoo this year, perhaps you might want to add a section for your session/paper. The format should be clear enough, and there is now a pretty complete help file. The URL for the Kalamazoo 2005 page is <http://sql.uleth.ca/dmorgwiki/index.php/Kalamazoo_2005>. I've also started a page for Leeds 2006, but have nothing other than the name there. If you are speaking or organising something at Leeds, you might want to add it to the Wiki at <http://sql.uleth.ca/dmorgwiki/index.php/Leeds_2005> Perhaps when the conference is over, speakers might want to link their abstracts, slides, or text to this page. The Spring 2006 issue of DM (submission deadline, December 31st, 2005) will feature papers from the Summer 2005 conference season. Finally, I've started pages for Kalamazoo and Leeds 2006: I thought perhaps we might be able to collaboratively work out paper topics using these pages, though I'm not sure that will work. <http://sql.uleth.ca/dmorgwiki/index.php/Leeds_2006> <http://sql.uleth.ca/dmorgwiki/index.php/Kalamazoo_2006> -dan -- Daniel Paul O'Donnell, PhD Associate Professor of English University of Lethbridge Lethbridge AB T1K 3M4 Tel. (403) 329-2377 Fax. (403) 382-7191 E-mail <daniel.odonnell(a)uleth.ca> Home Page <http://people.uleth.ca/~daniel.odonnell/> The Digital Medievalist Project: <http://www.digitalmedievalist.org/>

2 1

RE: [dm-l] what xslt can't do..?
by Binkley, Peter 08 Apr '05

08 Apr '05

I confess I haven't tried Anastasia yet, through lack of time and not of interest. Glancing at the documentation, I see that Anastasia appears to do lookups in a book file, which has (previously?) been compiled from the TEI. ("This must be an Anastasia book compiled from the XML using the Anastasia GroveMaker tool. This is designed to permit fast, real-time access to any part of the underlying XML.") Anastasia's speed is attributed to the fact that it is "interrogating not the source XML but a set of binary files (an "AnaGrove") which are optimized to permit the fastest access to information about every aspect of the source XML." GroveMaker is written in C. It would appear, then, that Anastasia would have the same syncronization requirements as the kind of pre-transformed XSL-based solution that James is talking about: if you change the TEI, you've got to remember to recompile the AnaGrove. If I've understood this correctly, then it seems to me that the correct object of comparison for Anastasia's ability to present an arbitrary page would not be a single-pass XSL against a large TEI file, but rather, say, a Cocoon pipeline using XSL to present arbitrary XML page files which have been pre-extracted from the TEI file and optimized for presentation by an XSL process along the lines of the one I hacked. The TCL scripts that Peter R. sent would be the equivalent of the matcher and generator in the Cocoon pipeline: <map:match pattern="*/*.html"> <map:generate src="path-to-texts/{1}/{2}.xml"/> ... </map:match> (where a url like "hengwrt/23.html" would be mapped to an extracted page file "path-to-texts/hengwrt/23.xml"). The output of this generator, as of the TCL scripts, is the marked-up text of a given page, ready to be styled and presented to the reader. Anastasia may well still win on speed, of course, if not in the presentation then in the preprocessing. An XSL-based extraction process will have a hard time keeping up with a custom-written C indexer. But it will be a lot easier to maintain, I submit (with apologies if I've misunderstood what Anastasia is doing). Has anyone looked at teiPublisher yet, by the way? (http://teipublisher.sourceforge.net/docs/index.php) Judging from the texts in the "Documenting the American South" project, they seem to have sidestepped the whole problem of presenting arbitrary pages, by only offering the complete text in a single HTML file. I haven't looked into it to see if there are other options, though. Final note regarding the sample text: again, I don't understand what the problem is with the last page, even with the appendix. How can any process know that that last div is an appendix and not a new section of the main text, beginning and ending on page 5? Whatever marker GroveMaker uses to make this distinction would also be available to XSL, presumably. (Perhaps my ignorance of TEI is showing...) Peter Binkley > -----Original Message----- > From: dm-l-bounces(a)uleth.ca [mailto:dm-l-bounces@uleth.ca] On > Behalf Of Peter Robinson > Sent: Friday, April 08, 2005 12:11 AM > To: dm-l(a)uleth.ca > Subject: RE: [dm-l] what xslt can't do..? > > The Digital Medievalist List (see end of message for contact > information and project URLs). > > ---------------------------------- > Peter (Binkley) has already pointed out the problems with the > XSLT approach he took. > I think even the fix he suggests, of returning a stripped > node fragment, would still lead to performance problems (for > instance..to pull a single page say out of the Hengwrt > Chaucer you would need every time to read the WHOLE document > to create the node sets for ALL pages, just so you could > extract the node set for just one, every time). There is > also a problem with the last page. Presume that we have, > indeed, what we always have: a whole bunch of other text in > separate divs in the document after the last page, as below. > Here is a new div containing an > appendix: > Peter B's approach would include that text, wrongly, in the > node set for the last page. I'm sure this could be fixed > (get the node sets only for the pbs in the div holding them) > but it is just yet another complication. (Incidentally, the > best solution to the 'missing last end of page' problem, and > ideed to various other problems, is what Steve De Rose > describes as 'trojan milestones': see > http://www.mulberrytech.com/Extreme/Proceedings/html/2004/DeRo > se01/EML2004DeRose01.html). > > I think too there is some misconception about just how the > system I use > (Anastasia) > would cope with this problem. Peter B(inkley) suggests it is > some kind of 'coded project', apparently using Java, while > Peter B(aker..this is ridiculous) seems to think I would be > using raw C. For the many who do not seem to have looked yet at > Anastasia: it provides a tcl scripting environment which lets > you manipulate XML easily in some ways (including ways very > important to us) which XLST finds difficult. Particularly -- > the whole focus of this discussion -- it is straight-forward > in Anastasia to manipulate a document according to > alternative hierarchies implicit in the element relations: so > you can show just one column or one page of a text otherwise > structured in hierarchical divisions. > > Thus, the whole Anastasia code to pull out the first two > pages of this document looks like this: > > proc begin {book me stylename} { > global pagecounter startEl > set pagecounter 0 > set startEl [findSGElement "stag(\"pb\") with attvalue(\"1\")"] } > > proc pb {me context} { > global pagecounter finish > if {$pagecounter=="2"} {set finish 1} > incr pagecounter > } > > Folks, that is all there is. The 'begin' function finds the > first page by its attribute value (there are other ways one > could do it, to be sure that this is the first page) and sets > Anastasia to start reading the document right there. > The 'pb' > function counts every page every time it hits a pb: when the > pagecounter reaches '2' > it has read two full pages and setting the 'finish' variable > to 1 stops the output. > One could include a few more proc functions to format the > headings, paragraphs, etc, or one could identify the last > page by attribute value, but that is all. > And it does this just as quick for a document with 100000 > pages as one. > > I don't have a prejudice against XSLT, which seems a fine > tool for doing most of the things one wants to do with XML. > But that does not mean it can do *everything* equally easily > (which is how this whole thread started, with musings on its > limits as a typesetting language). Some things certainly > Anastasia does much easier, and that is no surprise -- it was > designed just for that. She is open source. Go look at her > on http://anastasia.sourceforge.net Peter R(obinson) > > ***revised document with an appendix after the last page... > <div> > <head>The whole text and all the texts</head> <div> <pb > n="1"/> <head>First text</head> <p n="1">some text starts > here and goes ita<hi rend="italic">lic an<pb n="2"/>d > then</i> we get a pagebreak</p> <p n="2">so the text > finishes</p> <p n="3"> with yet another page <pb n="3"/> and > another page start </p> </div> <div> <head>Second text</head> > <pb n="4"/> <p n="1">here my new text on the next page etc > etc</p> <pb n="5"/> <p n="2">here my new text on the next > page etc etc</p> </div> <div> <p>Now here we have an appendix > and some more text after that</p> </div> </div> > > > > _______________________________________________ > Digital Medievalist Project > Homepage: http://www.digitalmedievalist.org Journal (December > 2004-): http://www.digitalmedievalist.org/journal.cfm > RSS (announcements) server: > http://www.digitalmedievalist.org/rss/rss2.cfm > Wiki: http://sql.uleth.ca/dmorgwiki/index.php > Change membership options: > http://listserv.uleth.ca/mailman/listinfo/dm-l > Submit RSS announcement: http://www.digitalmedievalist.org/newitem.cfm > Contact editorial Board: digitalmedievalist(a)uleth.ca dm-l > mailing list dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l >

1 0

RE: [dm-l] what xslt can't do..?
by Peter Robinson 08 Apr '05

08 Apr '05

Peter (Binkley) has already pointed out the problems with the XSLT approach he took. I think even the fix he suggests, of returning a stripped node fragment, would still lead to performance problems (for instance..to pull a single page say out of the Hengwrt Chaucer you would need every time to read the WHOLE document to create the node sets for ALL pages, just so you could extract the node set for just one, every time). There is also a problem with the last page. Presume that we have, indeed, what we always have: a whole bunch of other text in separate divs in the document after the last page, as below. Here is a new div containing an appendix: Peter B's approach would include that text, wrongly, in the node set for the last page. I'm sure this could be fixed (get the node sets only for the pbs in the div holding them) but it is just yet another complication. (Incidentally, the best solution to the 'missing last end of page' problem, and ideed to various other problems, is what Steve De Rose describes as 'trojan milestones': see http://www.mulberrytech.com/Extreme/Proceedings/html/2004/DeRose01/EML2004D…). I think too there is some misconception about just how the system I use (Anastasia) would cope with this problem. Peter B(inkley) suggests it is some kind of 'coded project', apparently using Java, while Peter B(aker..this is ridiculous) seems to think I would be using raw C. For the many who do not seem to have looked yet at Anastasia: it provides a tcl scripting environment which lets you manipulate XML easily in some ways (including ways very important to us) which XLST finds difficult. Particularly -- the whole focus of this discussion -- it is straight-forward in Anastasia to manipulate a document according to alternative hierarchies implicit in the element relations: so you can show just one column or one page of a text otherwise structured in hierarchical divisions. Thus, the whole Anastasia code to pull out the first two pages of this document looks like this: proc begin {book me stylename} { global pagecounter startEl set pagecounter 0 set startEl [findSGElement "stag(\"pb\") with attvalue(\"1\")"] } proc pb {me context} { global pagecounter finish if {$pagecounter=="2"} {set finish 1} incr pagecounter } Folks, that is all there is. The 'begin' function finds the first page by its attribute value (there are other ways one could do it, to be sure that this is the first page) and sets Anastasia to start reading the document right there. The 'pb' function counts every page every time it hits a pb: when the pagecounter reaches '2' it has read two full pages and setting the 'finish' variable to 1 stops the output. One could include a few more proc functions to format the headings, paragraphs, etc, or one could identify the last page by attribute value, but that is all. And it does this just as quick for a document with 100000 pages as one. I don't have a prejudice against XSLT, which seems a fine tool for doing most of the things one wants to do with XML. But that does not mean it can do *everything* equally easily (which is how this whole thread started, with musings on its limits as a typesetting language). Some things certainly Anastasia does much easier, and that is no surprise -- it was designed just for that. She is open source. Go look at her on http://anastasia.sourceforge.net Peter R(obinson) ***revised document with an appendix after the last page... <div> <head>The whole text and all the texts</head> <div> <pb n="1"/> <head>First text</head> <p n="1">some text starts here and goes ita<hi rend="italic">lic an<pb n="2"/>d then</i> we get a pagebreak</p> <p n="2">so the text finishes</p> <p n="3"> with yet another page <pb n="3"/> and another page start </p> </div> <div> <head>Second text</head> <pb n="4"/> <p n="1">here my new text on the next page etc etc</p> <pb n="5"/> <p n="2">here my new text on the next page etc etc</p> </div> <div> <p>Now here we have an appendix and some more text after that</p> </div> </div>

4 4

RE: [dm-l] what xslt can't do..?
by Binkley, Peter 07 Apr '05

07 Apr '05

I agree with James (mind if we call you Peter, just to keep things clear?) that a multi-pass approach is likely to be more efficient than mine, just because of the overhead mine incurs in creating nodesets all the time. What my approach needs is a function that takes a node-set and returns a tree fragment containing those nodes and all their ancestors, with non-ancestors stripped out. Does XSLT2 provide such a function? I haven't got into 2 yet. If not, it probably wouldn't be too hard to write up a Java extension to do it. For situations requiring the kind of performance that Peter Robinson is talking about, XSLT will probably always have value only as a prototyping tool, to be replaced by coded projects like Peter's. But I think it has more value as a prototyping tool than Peter R. is giving it credit for. I think a better Java programmer than me (i.e. any Java programmer) would still have taken longer than I did to prototype a solution to Peter's challenge, and would have required more than 63 lines of code to do it. Peter Binkley Peter Binkley, Ph.D., MLIS Digital Initiatives Technology Librarian Information Technology Services 4-30 Cameron Library University of Alberta Libraries Edmonton, Alberta Canada T6G 2J8 Phone: (780) 492-3743 Fax: (780) 492-9243 e-mail: peter.binkley(a)ualberta.ca > -----Original Message----- > From: dm-l-bounces(a)uleth.ca [mailto:dm-l-bounces@uleth.ca] On > Behalf Of James Cummings > Sent: Thursday, April 07, 2005 05:07 AM > To: Digital Medievalist Community mailing list > Subject: Re: [dm-l] what xslt can't do..? > > The Digital Medievalist List (see end of message for contact > information and project URLs). > > ---------------------------------- > > I've always been happy to agree with Peter(Robinson) that > XSLT has some major limitations. I, like Peter(Baker) think > that a solution can be found within XSLT for this problem. > My approach would be, like > Peter(Baker) suggests, to do multiple transforms. > Increasingly I'm doing this not as a set of discrete files > (though the modularity of that is very attractive), but > through using variables in XSLT2 which can then have further > operations applied to them. i.e. creating temporary trees > since you can continue to work on so-called result tree > fragments in XSLT2. But Peter Binkley has solved the > specific problem in his post. > > However, as a general approach, I like to see the first step > as a conversion of one hierarchy to another, so converting > every element in the document to milestone like elements > indicating start and end. The priviledging that set of > milestones that are most important to you for that transformation. > > But the XML could have been encoded as such to begin with > couldn't it? > So perhaps the problem isn't that it can be difficult in XSLT > to transform from one arbitrary hierarchy to another, but > that the choice of hierarchy should be suited to the purpose. > If the aim is to display pages, then priviledge that > hierarchy and break the other ones? > > I've knocked up a quick XSLT1 stylesheet that takes any XML > document as an input, and wraps it in a document element and > creates all other elements (except <head> and <pb/> ;-) ) as > milestone elements indicating their start and end. > > So, passing the text.xml through it, I get: > -------------- > <document> > <div start="true"/> > <head>The whole text and all the texts</head> > <div start="true"/> > <pb n="1"/> > <head>First text</head> > <p start="true" n="1"/>some text starts here and > goes ita<hi start="true" rend="italic"/>lic an<pb n="2"/>d > then<hi end="true" > rend="italic"/> we get a pagebreak<p end="true" n="1"/> > <p start="true" n="2"/>so the text finishes<p > end="true" n="2"/> > <p start="true" n="3"/> with yet another page <pb > n="3"/> and another page start <p end="true" n="3"/> > <div end="true"/> > <div start="true"/> > <head>Second text</head> > <pb n="4"/> > <p start="true" n="1"/>here my new text on the > next page etc etc<p end="true" n="1"/> > <pb n="5"/> > <p start="true" n="2"/>here my new text on the > next page etc etc<p end="true" n="2"/> > <div end="true"/> > <div end="true"/> > </document> > -------------- > Then one could fairly easily use an xsl:for-each-group > solution to group elements by <pb>. For what it is worth > (and it could be done in a more sophisticated and efficient > manner) the XSLT for milestoning a document that I knocked up was: > -------------- > <?xml version="1.0" encoding="utf-8"?> > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > version="1.0"> > <xsl:output method="xml" indent="no" encoding="utf-8"/> > <xsl:template match="/"> > <document> > <xsl:call-template name="element-start"/> > <xsl:apply-templates/> > <xsl:call-template name="element-end"/> > </document> > </xsl:template> > <xsl:template match="*" priority="-1"> > <xsl:call-template name="element-start"/> > <xsl:apply-templates/> > <xsl:call-template name="element-end"/> > </xsl:template> > <xsl:template match="head"> > <head> > <xsl:apply-templates/> > </head> > </xsl:template> > <xsl:template match="pb"> > <pb> > <xsl:for-each select="@*"> > <xsl:attribute name="{name()}"> > <xsl:value-of select="."/> > </xsl:attribute> > </xsl:for-each> > </pb> > </xsl:template> > <xsl:template name="element-start"> > <xsl:element name="{name()}"> > <xsl:attribute name="start">true</xsl:attribute> > <xsl:for-each select="@*"> > <xsl:attribute name="{name()}"> > <xsl:value-of select="."/> > </xsl:attribute> > </xsl:for-each> > </xsl:element> > </xsl:template> > <xsl:template name="element-end"> > <xsl:element name="{name()}"> > <xsl:attribute name="end">true</xsl:attribute> > <xsl:for-each select="@*"> > <xsl:attribute name="{name()}"> > <xsl:value-of select="."/> > </xsl:attribute> > </xsl:for-each> > </xsl:element> > </xsl:template> > </xsl:stylesheet> > -------------- > > -James > -- > Dr James Cummings, Oxford Text Archive, University of Oxford > James dot Cummings at oucs dot ox dot ac dot uk > > _______________________________________________ > Digital Medievalist Project > Homepage: http://www.digitalmedievalist.org > Journal (December 2004-): > http://www.digitalmedievalist.org/journal.cfm > RSS (announcements) server: > http://www.digitalmedievalist.org/rss/rss2.cfm > Wiki: http://sql.uleth.ca/dmorgwiki/index.php > Change membership options: > http://listserv.uleth.ca/mailman/listinfo/dm-l > Submit RSS announcement: http://www.digitalmedievalist.org/newitem.cfm > Contact editorial Board: digitalmedievalist(a)uleth.ca > dm-l mailing list > dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l >

1 0

RE: [dm-l] what xslt can't do..?
by Peter Robinson 07 Apr '05

07 Apr '05

>Now Peter, I'm perfectly happy to take on this problem, but I think we >both know that your demand that the transform be done in one pass makes >it not so much "slightly more of a challenge" as "impossible." But what >would be the problem with doing the transform in two passes, or three, >or four? One could wrap them all up in some Python or Java, and the user >wouldn't know or care. Assuming we can get past this little issue, why >yes, I think it can be done, and I'll be happy to give it a try. Notice >another qualification in my note: "when we've all got lots of time." You know, I think that is my whole point. There are indeed circumstances where the transform solution is very difficult. My document sample is one such. Notice that the first page break occurs some way into the document; and there is no explicit 'end of page' for the last page break. So figuring out the logic, by which you turn the empty page breaks into content-holding elements, is rather non-trivial. The transform solution is also going to be a real problem, for performance reasons, when you have documents of thousands of pages and you need to process them dynamically (*Not* pre-filter them through transforms). As for needing lots of time: if your tools let you do what you want directly with the document as it is, without the need for complex transforms, you don't need it. I give a summary on why the system-we-have-not-named can handle this kind of problem easily, where XSLT can not, on http://anastasia.sourceforge.net/comparexsl.html. And, she-who-we-do-not-name can indeed do many of the things listed as XSLT no-nos on the http://www.dpawson.co.uk/xsl/sect2/nono.html pages (change variable values, create an xpath expression from a variable, move entities from the input to the output file, etc etc). all the best Peter

2 1

what xslt can't do..?
by Peter Robinson 07 Apr '05

07 Apr '05

Peter Baker says... >I must say, though, Peter, that this isn't the first time you've >mentioned things that XSL can't do. I'm not sure I believe that it can't >be done. Someday, when we've all got lots of time, we'll have to have a >programming shootout. You can offer up a problem that you think XSL >can't handle, and you code it in C (or whatever it is you use), and I'll >use XSLT, and we'll see who gets there first. indeed, I have become rather a bore on this subject. And I have several times pointed out that XSLT has great difficulty with what is conceptually a simple task: just show me the text on one page. I have several times set the challenge: somebody, try and do with XSLT what we do for many thousands of pages (in the most basic form; just reproduce what we do for a single page of the Hengwrt Chaucer, for example). I have had some extremely lengthy explanations of how it *could* be done, and I am certainly prepared to believe these might actually work. In the same way, I am sure that with sufficient ingenuity one could use a lawnmower to heat a house. Just, one might find easier ways to do it. So, here is a simple example, then: <div> <head>The whole text and all the texts</head> <div> <pb n="1"/> <head>First text</head> <p n="1">some text starts here and goes ita<hi rend="italic">lic an<pb n="2"/>d then</i> we get a pagebreak</p> <p n="2">so the text finishes</p> <p n="3"> with yet another page <pb n="3"/> and another page start </p> </div> <div> <head>Second text</head> <pb n="4"/> <p n="1">here my new text on the next page etc etc</p> <pb n="5"/> <p n="2">here my new text on the next page etc etc</p> </div> </div> So, Peter, here is your challenge. Just make us an xslt file that pulls out just the text on each of the five pages. It would be a nice bonus if each page were to have a header which told us what text there is on each page (for example: page 3 contains 'First text, para 3 -- Second text, head'; page 5 contains just 'Second text, para 5'). To make it slightly more of a challenge: you should do this direct from this sample, and not from a transform of this sample. By the way, notice the problematics about the final page break. Should it be.. <head>Second text</head> <pb n="4"/> <p n="1">here OR <head>Second text<pb n="4"/></head> <p n="1">here OR <head>Second text</head> <p n="1"><pb n="4"/>here Answers on the back of a postage stamp please. all the best Another Peter

4 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

dm-l April 2005