Dear Digital Medievalists,
I guess I can safely assume that several people here have an experience teaching the TEI, specifically to an audience of medievalists or historians. After teaching some workshops, I feel more and more that it is highly efficient to teach the TEI not alone, isolated, as a means to encode documents in a smart way, but putting the TEI XML at the center of the other technologies that make its interest immediately evident to the students. For instance, I have experienced that providing the students, when they're finished with their task of encoding a critical edition, with the Version Machine on the one hand and another set of XSLT producing a classic, print-like view of their document greatly helps them understanding not only what encoding is for, but also what they have been doing so far. I am even pondering whether or not including the use of eXist-db in a forthcoming course (which might be pushing it a bit far, I admit). Of course, since XSLT or XQuery are not really easy to grasp in a short period for people without any technical background, and it is not really evident to introduce them to the subtleties of those technologies. Still, it's probably good if the students get some idea of how technologies work together, instead of putting all their trust into the magic IT people will work on their smartly encoded TEI documents to "put them on the web" :)
I would be interested in a feedback of your practice: do you, when you teach the TEI, feel the need / manage to integrate notions about other tools and technologies of the XML family? And if so, how do you do that (proper introduction to XSLT? use of packaged tools like the v-machine? etc.).
Just curious :)
Marjorie
Dear Marjorie,
I totally agree with this approach. Although I have as yet very little practical teaching experience in this area, I am thinking about developing a module on using IT for humanities research for doctoral students. The approach I was planning to take is to teach them to program in Perl to process plain texts and TEI encoded documents (using the XML:Twig library). Instead of teaching Perl from scratch I would give them working little programs which they can then modify to suit their needs (a recipe book approach). I would also provide them with some basic XSLT and CSS, just enough to visualise the (original and processed) data in a browser. I think that a procedural language like Perl is easier to grasp than XSLT and to learn. Your suggestion of using packaged tools is certainly something I will now consider too.
It may well be that I am expecting too much from humanities reseachers, in terms of teaching them to program. I'd be interested to hear of people who've done something similar.
Best,
Godfried
-----Original Message----- From: dm-l-bounces@uleth.ca [mailto:dm-l-bounces@uleth.ca] On Behalf Of Marjorie Burghart Sent: 27 January 2011 23:15 To: dm-l@uleth.ca Subject: [dm-l] Teaching the TEI: your practice?
Dear Digital Medievalists,
I guess I can safely assume that several people here have an experience teaching the TEI, specifically to an audience of medievalists or historians. After teaching some workshops, I feel more and more that it is highly efficient to teach the TEI not alone, isolated, as a means to encode documents in a smart way, but putting the TEI XML at the center of the other technologies that make its interest immediately evident to the students. For instance, I have experienced that providing the students, when they're finished with their task of encoding a critical edition, with the Version Machine on the one hand and another set of XSLT producing a classic, print-like view of their document greatly helps them understanding not only what encoding is for, but also what they have been doing so far. I am even pondering whether or not including the use of eXist-db in a forthcoming course (which might be pushing it a bit far, I admit). Of course, since XSLT or XQuery are not really easy to grasp in a short period for people without any technical background, and it is not really evident to introduce them to the subtleties of those technologies. Still, it's probably good if the students get some idea of how technologies work together, instead of putting all their trust into the magic IT people will work on their smartly encoded TEI documents to "put them on the web" :)
I would be interested in a feedback of your practice: do you, when you teach the TEI, feel the need / manage to integrate notions about other tools and technologies of the XML family? And if so, how do you do that (proper introduction to XSLT? use of packaged tools like the v-machine? etc.).
Just curious :)
Marjorie
Dear Marjorie,
I would be interested in a feedback of your practice: do you, when you teach the TEI, feel the need / manage to integrate notions about other tools and technologies of the XML family? And if so, how do you do that (proper introduction to XSLT? use of packaged tools like the v-machine? etc.).
when I teach the use of TEI in course of mansucript description and/or digital editions a very important notion is the one that encoding has to be done with not only looking at what is there (e.g. in the source) but as well what the result of this exercise would have to look like.
"Don't encode what you don't use for research or presentation!"
Only if one knew what s/he wants to achieve "proper" encoding is possible. In order to know (or at least guess) what you *can* achieve I think its necessary to know a bit about the processing (e.g. XSLT) or the publishing process (e.g. DB plus XQuery).
But: An as strong point as the previous is to take into consideration that it might be helpful to (re!)establish the division of work: One to encode data and do or at least prepare research on the data and let someone else take responsibility for publishing both original data and research results. Although it has become common practice that researchers have to publish their work on their own ("Word is doing such good work"), in the field of DBs and X-technologies the gap between good contents and good "publication" is even deeper than it was in the age of print. (We only had forgotten that good print needs something more than just Word and were left with this task!) Thus the presentation to XSLT or DBs might be rather limited, more like just a glimpse to know what's out there.
Courses which show these aspects are: (information mainly in German, sorry)
http://www.hab.de/bibliothek/sammlungen/hzdfg/SCRIPTO/index.htm http://www.i-d-e.de/spring-school-2011
I consider all this is valid for all XML-based work not only TEI.
Best, Torsten
Dear Godfried,
Instead of teaching Perl from scratch I would give them working little programs which they can then modify to suit their needs (a recipe book approach).
although this seems to be perfectly reasonable,
I think that a procedural language like Perl is easier to grasp than XSLT and to learn.
I wonder how to prove this? Learning a (another) procedural language might be easier for someone who already learned a procedural language, but I find the way XSLT work so quite straight forward that once you understood how XML works it might be easy to understand XSLT too?! If you learned object oriented programming like Java, XML-processing with XSLT, XPath etc seems to be very similar?
But I admit it might be only me estimating this?
Best, Torsten
I wonder how to prove this? Learning a (another) procedural language might be easier for someone who already learned a procedural language, but I find the way XSLT work so quite straight forward that once you understood how XML works it might be easy to understand XSLT too?!
It is probably my limited knowledge of XSLT, but I find it quite difficult to do things with data in an XML structure (other than rearranging and displaying it).
I find the way variables work in XSLT just so cumbersome. I wouldn't know where to start doing complex regex operations in XLST, to be honest.
Godfried
I think it's certainly true that if you're used to a procedural language like Perl, a functional(ish) language like XSLT will seem bizarre. But I'm not sure XSLT is any stranger than any other programming language to someone without programming experience.
Hugh
On Jan 28, 2011, at 5:36AM, Torsten Schassan wrote:
Dear Godfried,
Instead of teaching Perl from scratch I would give them working little programs which they can then modify to suit their needs (a recipe book approach).
although this seems to be perfectly reasonable,
I think that a procedural language like Perl is easier to grasp than XSLT and to learn.
I wonder how to prove this? Learning a (another) procedural language might be easier for someone who already learned a procedural language, but I find the way XSLT work so quite straight forward that once you understood how XML works it might be easy to understand XSLT too?! If you learned object oriented programming like Java, XML-processing with XSLT, XPath etc seems to be very similar?
But I admit it might be only me estimating this?
Best, Torsten
-- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de
http://www.hab.de/forschung/projekte/europeana-regia.htm http://www.hab.de/forschung/projekte/weiss64.htm
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gid=49320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l
I do agree that how easy or difficult it is to learn a new technology depends to an extent on one's previous experience and knowledge.
But even then, I would be hard-pressed to see how XSLT would be better than Perl or a similar language when it comes to processing data in which which are not essentially to do with formatting XML documents for display.
If I wanted to, say, develop a program to lemmatise text marked up in paragraphs <p>, or parse Roman calendar dates marked up with <date>, is that something for which you would recommend using XSLT? XSLT would easily let you find that data, but I am not sure it would be easy to then process it in XSLT. Not having associative arrays or more complex data structures in XSLT makes that particularly hard, not?
Godfried
-----Original Message----- From: dm-l-bounces@uleth.ca [mailto:dm-l-bounces@uleth.ca] On Behalf Of Hugh Cayless Sent: 30 January 2011 03:09 To: Digital Medievalist Subject: Re: [dm-l] Teaching the TEI: your practice?
I think it's certainly true that if you're used to a procedural language like Perl, a functional(ish) language like XSLT will seem bizarre. But I'm not sure XSLT is any stranger than any other programming language to someone without programming experience.
Hugh
On Jan 28, 2011, at 5:36AM, Torsten Schassan wrote:
Dear Godfried,
Instead of teaching Perl from scratch I would give them working little programs which they can then modify to suit their needs (a recipe book approach).
although this seems to be perfectly reasonable,
I think that a procedural language like Perl is easier to grasp than XSLT and to learn.
I wonder how to prove this? Learning a (another) procedural language might be easier for someone who already learned a procedural language, but I find the way XSLT work so quite straight forward that once you understood how XML works it might be easy to understand XSLT too?! If you learned object oriented programming like Java, XML-processing with XSLT, XPath etc seems to be very similar?
But I admit it might be only me estimating this?
Best, Torsten
-- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de
http://www.hab.de/forschung/projekte/europeana-regia.htm http://www.hab.de/forschung/projekte/weiss64.htm
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gid=49320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gidI320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l
Dear Godfried,
But even then, I would be hard-pressed to see how XSLT would be better than Perl or a similar language when it comes to processing data in which which are not essentially to do with formatting XML documents for display.
I find it particular handy to operate on XML data in a code that is XML itself. As well XPath expressions might be way shorter (and clearer?) as Perl constructs? But it's a matter of taste.
If I wanted to, say, develop a program to lemmatise text marked up in paragraphs<p>, or parse Roman calendar dates marked up with<date>, is that something for which you would recommend using XSLT? XSLT would easily let you find that data, but I am not sure it would be easy to then process it in XSLT.
I would dare to say "They become more and more similar", e.g. with Perl coping better with XML while XSLT starts operating on the file system? As long as both are Turing-complete, it should be possible to implement every operation in both languages?
Not having associative arrays or more complex data structures in XSLT makes that particularly hard, not?
You aren't talking about XSLT2, are you? Because there we have e.g. temporary trees that make up for complex data structures and speed up the processing alot. Although processing data with a certain type of loop would also make up for that?
Best, Torsten
Dear Torsten,
Maybe I need to learn more XSLT. I have never looked at XSLT2, but found XLST1 quite cumbersome to do anything beyond mere reformatting of XML data.
Godfried
-----Original Message----- From: dm-l-bounces@uleth.ca [mailto:dm-l-bounces@uleth.ca] On Behalf Of Torsten Schassan Sent: 01 February 2011 14:43 To: dm-l@uleth.ca Subject: Re: [dm-l] Teaching the TEI: your practice?
Dear Godfried,
But even then, I would be hard-pressed to see how XSLT would be better
than Perl or a similar language when it comes to processing data in which which are not essentially to do with formatting XML documents for display.
I find it particular handy to operate on XML data in a code that is XML itself. As well XPath expressions might be way shorter (and clearer?) as Perl constructs? But it's a matter of taste.
If I wanted to, say, develop a program to lemmatise text marked up in
paragraphs<p>, or parse Roman calendar dates marked up with<date>, is that something for which you would recommend using XSLT? XSLT would easily let you find that data, but I am not sure it would be easy to then process it in XSLT.
I would dare to say "They become more and more similar", e.g. with Perl coping better with XML while XSLT starts operating on the file system? As long as both are Turing-complete, it should be possible to implement every operation in both languages?
Not having associative arrays or more complex data structures in XSLT
makes that particularly hard, not?
You aren't talking about XSLT2, are you? Because there we have e.g. temporary trees that make up for complex data structures and speed up the processing alot. Although processing data with a certain type of loop would also make up for that?
Best, Torsten
-- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de
http://www.hab.de/forschung/projekte/europeana-regia.htm http://www.hab.de/forschung/projekte/weiss64.htm
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gid=49320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l
Il giorno ven, 28/01/2011 alle 00.14 +0100, Marjorie Burghart ha scritto:
Dear Digital Medievalists,
I guess I can safely assume that several people here have an experience teaching the TEI, specifically to an audience of medievalists or historians. After teaching some workshops, I feel more and more that it is highly efficient to teach the TEI not alone, isolated, as a means to encode documents in a smart way, but putting the TEI XML at the center of the other technologies that make its interest immediately evident to the students.
I totally agree with that. My current practice (after teaching a bit of theory on markup, and the TEI fundamentals):
- teach some XSLT and have students experiment with it at once: this is really useful to put to test some of the key concepts I explained before (form-content separation, importance of selecting carefully *what* to markup, what Torsten wrote about visualizing the intended result in adnvance, etc.); - have them use IMT to learn about with <facsimile> and friends; - have them prepare a little encoding project to be discussed during the final exam: they choose the text, explain to me their markup strategy, then do everything on their own, including creating a custom schema (using Roma) and XSLT style sheets to produce an HTML version ... this is incredibly useful to expose lingering misconceptions and to really learn what is like to work on a 'real' markup project.
So far I'm quite satisfied with this sequence, will look into the versioning machine too :) unfortunately I doubt I'd have the time to explain XML DBs (that would be needed as well, of course).
Ciao
Roberto
-
Croenen, Godfried -
Hugh Cayless -
Marjorie Burghart -
Roberto Rosselli Del Turco -
Torsten Schassan