dm-l

dm-l@uleth.ca

2786 discussions

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

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

07 Apr '05

I've just noticed that I hadn't removed some unnecessary lines, evidence of a false start; the stylesheet is now down to 63 lines. Peter -----Original Message----- From: dm-l-bounces(a)uleth.ca on behalf of Binkley, Peter Sent: Thu 4/7/2005 3:33 AM To: peter.robinson(a)dmu.ac.uk; Digital Medievalist Community mailing list; 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). ----------------------------------

1 0

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

07 Apr '05

Unless I've misunderstood the challenge, I think this 70-line, single-pass stylesheet will fill the bill: http://www.wallandbinkley.com/robinsonchallenge/paginate.xsl . Peter's XML text is available here: http://www.wallandbinkley.com/robinsonchallenge/text.xml . The output looks like this: <document> <head>The whole text and all the texts</head> <page n="1"> <pageheader>Text 1, para 1</pageheader> <div> <head>First text</head> <p n="1">some text starts here and goes ita<hi rend="italic">lic an</hi></p> </div> </page> <page n="2"> <pageheader>Text 1, paras 1, 2 and 3</pageheader> <div> <p n="1"><hi rend="italic">d then</hi> we get a pagebreak</p> <p n="2">so the text finishes</p> <p n="3"> with yet another page </p> </div> </page> ... </document> The pages are presented in discrete elements, each containing only the text of that page, with all markup preserved and all tags well-formed. The basic mechanism involves using a key to index all the text nodes by their page number: <xsl:key name="text" match="text()" use="preceding::pb[1]/@n"/> It is then easy to create a node-set containing all the text nodes for a given page, like this: <xsl:variable name="texts" select="key('text', $thispage)"/> With that we can process the ancestors of those text nodes to create the output for that page, like this: <xsl:apply-templates select="/div/*[.//text()[count(.|$texts) = count($texts)]][1]"> As it stands this stylesheet is horribly inefficient, since it has to rebuild the node-set of text nodes every time it executes a template (since you can't pass a node-set as a parameter). Perhaps there's a way to move all the processing into the main for-each loop to avoid using templates. I'm not sure I understand why the final page break is problematic. Why would you want anything other than the way it is marked up in the source? (I notice that I've neglected to include the text 2 head in the page header, as in the example "Second text, head", and my punctuation doesn't match that example, but I'm too tired to fix it now.) Peter Binkley peter.binkley(a)ualberta.ca -----Original Message----- From: dm-l-bounces(a)uleth.ca on behalf of Peter Robinson Sent: Wed 4/6/2005 3:13 PM To: dm-l(a)uleth.ca Subject: [dm-l] what xslt can't do..? The Digital Medievalist List (see end of message for contact information and project URLs). ---------------------------------- 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 _______________________________________________ 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

2 1

tex, unicode, etc
by Peter Robinson 06 Apr '05

06 Apr '05

> > I won't try to cover any of the ground that John > McChesney-Young has > > covered in his post, except to say that that is also my > sense of the > > state of LaTeX right now: support for UTF-8 is still clunky, and > > Unicode/OpenType fonts are not natively supported. To judge > from its > > website the promising Omega project seems to have stalled. > To follow this up: on at least one operating system, matters are rather different. In Mac OS X, there is a quite wonderful TeX implementation named XeTeX: go see http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=xetex. This does Utf-8 right out of the box -- CJK, Thai (with hyphenation tables even!!), Arabic, Mongolian, polytonic greek, just anything as far as I can see. It also seems to work nicely with OpenType font families, etc. It also works seamlessly with LaTeX, including some real tricksy bits of LaTeX (long tables, for instance, spanning many pages). I got this running from bare ground to making Arabic pdfs in about 30 minutes -- you have to install the full TeX, XeTeX, and a graphic UI, TeXShop (which creates pdfs straight out of the TeX, which is very cool), but all this is nicely explained on the XeTeX site. I don't yet know whether XeTeX works ok with the EDMAC critical edition macros, but there's no reason why it should not. I'd have to say that TeX is still, after all these years, just the best typesetting system I have seen. I agree with Dan, that it is annoying in that appartently simple things (changing page sizes!) can be hard to do in TeX. But boy, does it make up for it in its power to make really complex, really beautiful pages. I am currently setting some 10,000 pages of a historical edition (about 9,000,000 words) from XML, and for a task like this, TeX is incomparable. We use our own transformer tool to translate the xml into tex source, and away we go (as always, we have to do dicy things like make up pages from bits of other pages mosaiced together, with lots of text bounded by empty elements, so XSL does not cut it for us). all the best Peter

3 2

Jump to page:

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