Hi David and everyone,
At 07:08 AM 8/18/2008, Marcus Bingenheimer wrote:
>With the help of Christian Wittern we have in recent years
>experimented to devise a syllabus for humanities computing. In the
>latest version I teach XML, TEI, and RelaxNG in one semester and
>XPath, XSLT and a bit of XQuery in the second. In the second year a
>colleague teaches Python and an introduction to online Databasing with
>MySQL and PHP.
This sounds like a very solid approach.
>Our experiments to establish this curriculum are not representative
>especially because our student numbers are too low (2-7 students per
>course). However, over the last three or four years I have come more
>and more to believe that it might be better to start with a general
>purpose scripting language. (Here we prefer Python over Perl, but
>there shouldn't be a big difference.) I am now thinking to teach the
>XML-tech module in two semesters later in the course.
I think this is a very interesting conclusion -- especially since I
had wondered the same thing on reading David's first post on the topic.
By structuring things this way, you address a central problem having
to do with students' understanding of the application stack, and in
particular the problems that arise when students work at one layer of
the stack (the markup and markup processing layer) without
understanding anything about what happens underneath it.
On the other hand, one could argue that the whole point of XML is to
make this possible, and indeed that when it is not (when we run into
problems at the edges of our systems, such as in dealing with
character encoding issues, text-based heuristics or what have you),
learning to negotiate and manage these boundaries is in itself a useful skill.
And of course there is the related issue of the practicality of the
fuller curriculum for students who are presumably concentrating their
>One big unsolved problem when teaching computing to scholars in the
>humanities is that most people will want to build some kind of
>web-application for their project in the end. However, administering a
>LAMP stack or any other application setup involves all kinds of
In a not dissimilar course at the University of Illinois' Library/IS
program (GSLIS), I have had students work, over a semester, with XML
and XSLT, and dealt with this problem by offering them the option of
deploying a final project in Cocoon. This worked well, but I don't
think it's for everyone. For one thing, GSLIS has excellent technical
support, and Cocoon can be fiddly.
>Sorry, if that misses your question somewhat, but for me the questions
>has been recently: Teaching a little programming to humanity scholars
>is no problem, but where to stop?
>XML-technologies in particular seem to make sense only in a web
>context with some form of dynamic output.
I agree that's the sweet spot, although I hasten to add that at least
at the graduate level, more than one of my students also demonstrated
that this doesn't have to be the case, in projects such as
bibliographic or data-aggregation applications, which didn't have web
interfaces but which were nonetheless demonstrably useful.
Like most design problems, I think this one is very sensitive to
local requirements. My own XSLT-centered syllabus will be changing
quite a bit now that I've taught the course once, but I can say that
one thing I did right was to foreground the application stack very
early on, in order to present to the students what parsing and raw
text processing was about, and why it's useful and important, even in
the recognition that we weren't going to be spending many cycles
working on it. Then when we butted up against the problems later in
the term (for example in discussion of upconversion problems), we
could at least recognize what they were.
Wendell Piez mailto:[log in to unmask]
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
Mulberry Technologies: A Consultancy Specializing in SGML and XML