dm-l June 2004

dm-l@uleth.ca

39 participants
39 discussions

RE: [dm-l] [Fwd: The time has come to make some <choice>s]
by Binkley, Peter 29 Jun '04

29 Jun '04

For those of us who are new to TEI (ok, just me, then), would someone care to gloss this? P5? Janus tags? Peter Peter Binkley 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: Daniel O'Donnell [mailto:daniel.odonnell@uleth.ca] > Sent: Monday, June 28, 2004 06:22 PM > To: Digital Medievalist list > Subject: [dm-l] [Fwd: The time has come to make some <choice>s] > > > Hello all, > I realise that many of us are on the TEI list and hence have seen > this; it is an important question, however, and I thought I would > distribute it here as well. If you are just beginning in computer > applications, the issue is fairly advanced (though it has > already come > up), and you're not likely to write a position paper on it in > the next > 30 days; I hope in this one instance, you'll forgive me for not > explaining it unless asked. > -dan > > -------- Original Message -------- > Subject: The time has come to make some s > Date: Mon, 28 Jun 2004 19:20:35 -0400 > From: Syd Bauman <Syd_Bauman(a)BROWN.EDU> > Reply-To: editors(a)tei-c.org > To: TEI-L(a)LISTSERV.BROWN.EDU > > > > CALL FOR VOLUNTEERS TO INFLUENCE P5! > ---- --- ---------- -- --------- --- > > Over the last year there has been some public discussion of > the "replacement Janus" mechanism for P5. The quick overview > is that, in order to avoid putting content (which might need > markup) in attribute values (which can't have markup), it has > been suggested that we change the so-called Janus tags from > things like > > <corr sic="adnire">admire</corr> > <orig reg="w">vv</orig>ith <orig reg="w">vv</orig>hat charity > the <abbr expan="Text Encoding Initiative Consortium">tei-c</abbr> > > to things like > > <choice> > <sic>adnire</sic> > <corr>admire</corr> > </choice> > <choice><orig>vv</orig><reg>w</reg></choice>ith > <choice> > <reg>w</reg> > <orig>vv</orig> > </choice>hat charity the > <choice src="abbr"> > <abbr>tei-c</abbr> > <expan>Text Encoding Initiative Consortium</expan> > </choice> > > The TEI Council would like to enlist the assistance of > interested parties in helping them consider the issues > involved. Therefore, this is a call for volunteers to write > up a short working paper on the issues surrounding the use of > the new mechanism and of the previous attribute mechanism. > (Note that some have referred to the new mechanism as the > "choice" mechanism, but the name of the element used in the > examples above is not carved in stone, and is one issue the > authors of this working paper may wish to address.) > > Current thinking is that a first draft of the paper should be > ready by Sat 07 Aug, and the final version should be ready on > Thu 16 Sep. > > Interested volunteers should reply to editors(a)tei-c.org. > > > -- > 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/> > > > > > _______________________________________________ > dm-l mailing list > dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l >

3 2

Re: [dm-l] MS-Internet Explorer 6 and standards based computing
by Joris van.Zundert 28 Jun '04

28 Jun '04

>>in short, yes. MSIE is the regular target of complaints from the web >>standards community. I second that. >>perhaps the response among this group should be the converse of many >>web developers: develop standards-based texts and applications and >>require your users to use standards-based browsers. Succesfullness of a webtool/application is often decided by whether it's well usable in the most popular browser (which too bad still is IE). If it's not, users will blame the application, not the browser. So I wouldn't recommend not making your application IE compatible. One should do both: implement the standards and provide a IE compatible version as well. >>even if IE is parsing XSL better right now, other browsers, >>particularly mozilla-based browsers, are sure to catch up. Although I doubt whether IE parses better, I wonder why one wouldn't just parse server side and sending HTML? For those who want the very XML, a download button, FTP, or OAI solution may be provided. HTML is implemented fairly reliable over all browsers, is it? Or do I fail to see an important point for not parsing XML server side? grtz, Joris

9 21

Re: Re: [dm-l] palaeography and computing
by Dorothy C. Porter 28 Jun '04

28 Jun '04

Arianna, -----Original Message----- From: Arianna Ciula <arianna.ciula(a)kcl.ac.uk> Date: Mon, 28 Jun 2004 18:05:17 +0100 Subject: Re: [dm-l] palaeography and computing Hi Dorothy, thank-you for all the information. I was at the ALLC/ACh conference in Sweden and I had ettended your talk of course, which I enjoied a lot. D: Thank you! By the way, what I'm curious about it's exactly what you call "encoding paleographical descriptions using a simple template interface". D: Rather than entering markup into the text by hand (think NoteTab Pro), the editor uses a template to compare the letter to be described with other (example) letters and selects descriptive elements from drop-down menus - the markup is entered automatically (and you don't need to look at the tags if you don't want to). It's a very user-friendly approach. Dot Looking forward your publications, Best wishes, Arianna Ciula On Mon, 28 Jun 2004 11:52:40 -0400 "Dorothy C. Porter" <Dorothy.Porter(a)uky.edu> wrote: > Arianna, > > We (Research in Computing for Humanities at the University of Kentucky) are working on DTD and tool (called "DucType") for paleographical description. Briefly, it will enable to editor to view a manuscript image alongside a transcript, and encode paleographical descriptions using a simple template interface. It's still under development, although Kevin Kiernan, PI on the projects, has shown several demonstrations, including one at Kzoo in May. > > Look for our forthcoming article in Literary and Linguistic Computing (the proceedings from last year's ACH/ALLC meeting - July or August 2004). We also have a short article coming out in the July DigiCULT Newsletter [http://www.digicult.info/pages/index.php] that gives a bit of history and briefly describes DucType and our other editing tools. > > You can find out more on our project websites: > > Electronic Boethius - http://beowulf.engl.uky.edu/~kiernan/eBoethius/inlad.htm > ARCHway - http://beowulf.engl.uky.edu/~kiernan/ARCHway/entrance.htm > > Hope this helps, > > Dot > > Arianna Ciula wrote: > > >Dear all, > > > >as a Ph.D. student working on palaeography and computing, I find this > >mailing list very useful and I start my contribution with a question. > > > >Is there any sort of DTD designed with the purpose of describing a > >medieval manuscript, not just in its physical features as a global > >object, but in its palaeographical features? > > > >I mean any kind of XML grill and hierarchy able to encounter > >description and comments on the shape of letters, of ligatures and so > >on, even related just to one period and one handwritten style. > > > >I know the TEI guidelines and the efforts of some specific projects such > >as Digital Scriptorium, but none of them seems to me to go into the > >image with the granularity needed for a palaeographical analysis. > > > >Cheers, > > > >Arianna Ciula > > > >---------------------- > >Arianna Ciula > >arianna.ciula(a)kcl.ac.uk > > > > > > > >_______________________________________________ > >dm-l mailing list > >dm-l(a)uleth.ca > >http://listserv.uleth.ca/mailman/listinfo/dm-l > > > > > > -- > 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/> > > > > > _______________________________________________ > dm-l mailing list > dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l > > > *************************************** > Dorothy Carr Porter, Program Coordinator > Collaboratory for Research in Computing for Humanities > University of Kentucky > 351 William T. Young Library > Lexington, KY 40506 > > dporter(a)uky.edu 859-257-9549 > *************************************** > > _______________________________________________ > dm-l mailing list > dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l > ---------------------- Arianna Ciula arianna.ciula(a)kcl.ac.uk *************************************** Dorothy Carr Porter, Program Coordinator Collaboratory for Research in Computing for Humanities University of Kentucky 351 William T. Young Library Lexington, KY 40506 dporter(a)uky.edu 859-257-9549 ***************************************

1 0

Re: [dm-l] palaeography and computing
by Dorothy C. Porter 28 Jun '04

28 Jun '04

Arianna, We (Research in Computing for Humanities at the University of Kentucky) are working on DTD and tool (called "DucType") for paleographical description. Briefly, it will enable to editor to view a manuscript image alongside a transcript, and encode paleographical descriptions using a simple template interface. It's still under development, although Kevin Kiernan, PI on the projects, has shown several demonstrations, including one at Kzoo in May. Look for our forthcoming article in Literary and Linguistic Computing (the proceedings from last year's ACH/ALLC meeting - July or August 2004). We also have a short article coming out in the July DigiCULT Newsletter [http://www.digicult.info/pages/index.php] that gives a bit of history and briefly describes DucType and our other editing tools. You can find out more on our project websites: Electronic Boethius - http://beowulf.engl.uky.edu/~kiernan/eBoethius/inlad.htm ARCHway - http://beowulf.engl.uky.edu/~kiernan/ARCHway/entrance.htm Hope this helps, Dot Arianna Ciula wrote: >Dear all, > >as a Ph.D. student working on palaeography and computing, I find this >mailing list very useful and I start my contribution with a question. > >Is there any sort of DTD designed with the purpose of describing a >medieval manuscript, not just in its physical features as a global >object, but in its palaeographical features? > >I mean any kind of XML grill and hierarchy able to encounter >description and comments on the shape of letters, of ligatures and so >on, even related just to one period and one handwritten style. > >I know the TEI guidelines and the efforts of some specific projects such >as Digital Scriptorium, but none of them seems to me to go into the >image with the granularity needed for a palaeographical analysis. > >Cheers, > >Arianna Ciula > >---------------------- >Arianna Ciula >arianna.ciula(a)kcl.ac.uk > > > >_______________________________________________ >dm-l mailing list >dm-l(a)uleth.ca >http://listserv.uleth.ca/mailman/listinfo/dm-l > > -- 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/> _______________________________________________ dm-l mailing list dm-l(a)uleth.ca http://listserv.uleth.ca/mailman/listinfo/dm-l *************************************** Dorothy Carr Porter, Program Coordinator Collaboratory for Research in Computing for Humanities University of Kentucky 351 William T. Young Library Lexington, KY 40506 dporter(a)uky.edu 859-257-9549 ***************************************

2 1

Re: [dm-l] palaeography and computing
by James Cummings 28 Jun '04

28 Jun '04

On Mon, 28 Jun 2004, Arianna Ciula wrote: > I know the TEI guidelines and the efforts of some specific projects such > as Digital Scriptorium, but none of them seems to me to go into the > image with the granularity needed for a palaeographical analysis. I would suggest posting specific examples of where you think TEI doesn't go far enough to the TEI-L list. They are always happy to see where they can improve. Digital Scriptorium's extensions are quite good. There is a good discussion of some of these issues at: http://www.hum.ku.dk/ami/handbook/ For those who haven't seen the manuscript description taskforce of TEI its activities are listed at: http://www.tei-c.org.uk/Activities/MS/ but I realise that concentrates on description rather that palaeographical analysis. These are all draft documents, however, and still have many errors that they will be correcting. -James --- Dr James Cummings, Oxford Text Archive, University of Oxford James dot Cummings at ota dot ahds dot ac dot uk

1 0

Re: [dm-l] MS-Internet Explorer 6 and standards based computing
by Joris van.Zundert 28 Jun '04

28 Jun '04

>>> Daniel O'Donnell <daniel.odonnell(a)uleth.ca> 6/28/04 15:48:51 >>> >>This is an interesting thread in as much as it touches on best practice. >>Leaving aside the server vs. client side serving of xml for a minute (do >>most people still not convert xml to (x)html and serve static pages?), Thank you for shortcutting the tedious answer I was preparing for that one ;-) Grtz., Joris

2 1

Useful free tools for finding unicode characters
by Daniel O'Donnell 28 Jun '04

28 Jun '04

The discussion of Junicode Wynn raises an interesting question: how can I find whether my system has a particular unicode character on it? For those who don't know, unicode is a universal coding system to describe characters (see <http://www.unicode.org/>). Before unicode, characters were largely associated with letters on the keyboard (I'm simplifying a bit). A predecessor of Peter Baker's Unicode font, Times Old English, used to work this way, for example. When you switched to that font in a wordprocessor and typed a letter (let's say "t"), some other character would appear on your screen (let's say thorn). The trouble was if you didn't have the right font, there was no way of recovering the missing character. What you intended as "thorn" would appear to your reader as "t". Unicode solves this problem by assigning individual characters a unique code point (there are millions of these code points available in the system). This means in theory (and largely in practice) that you no longer need to rely on a user having exactly your font in order to see your character; in fact you don't even need to know which font they will use: as long as they have a font that has the character in it, your document will be readable. In practice it isn't quite that simple, since many characters are not found in all or even many fonts. Wynn (01BF) is one of them. On my Windows XP system (which has hundreds of fonts installed), Wynn is present in only two: Junicode and Lucinda Sans Unicode. So while I can indicate that I mean wynn in a document by using the unicode code point 01BF, there is a good chance my user may not be able to see an actual wynn in my document unless, once again, they have the right fonts. If a character is commonly font in many fonts, you don't have to worry very much; if it is quite rarely included in fonts, you may have to provide a link to a font containing the right character. So how does one know if a specific character is a) present on my system or b) commonly or rarely found in fonts? There are several free tools and techniques you can use (these are windows based tools: I'd be interested in hearing about linux or mac based ones). One way of finding out if you have the character at all is to create a simple HTML document with the character and load it into a Mozilla-based browser (Netscape, Mozilla, K-meleon). These browsers have an algorithm they use to try and discover if any font on your system has characters required by your document but missing in the default font. It isn't perfect, but it is pretty good. If any font on your system has the character, these browsers are likely to find it. What they won't tell you is how common the character is or which fonts have the character you are looking for. To find out which specific fonts have your character, I recommend a tool built by Conal Tuohy, "Find Glyph." This is a small, quick, and simple utility that allows you to find out which fonts have the Unicode point you are looking for. I used this to find out that I have two fonts with wynn, for example. Find Glyph is available for free download at <http://www.nzetc.org/downloads/find-glyph.zip>. Another useful utility which seems to come and go on the web is Bjondi International's Character Agent. This won't tell you which fonts have a given character (I should be using the correct term, which is glyph, actually). But it does allow you to scroll through all the fonts on your system at a given unicode point regardless of whether the font in question has the character you are looking for (this is better than Character Map, a Windows utility, as Character Map only shows points in a font that have an actual glyph present). That was how I found out that Wynn is located in the Latin Extended B subrange. Character Agent is free, but I wasn't able to find a working link to it right now after a very quick search (Google throws up some links, but they seem to be outdated). Does anybody know of other handy tools? -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/>

5 4

MS-Internet Explorer 6 and standards based computing
by Daniel O'Donnell 26 Jun '04

26 Jun '04

Somebody a little while ago mentioned that IE 6 was better than previous version of Internet Explorer in its adherence to standards. We were talking at the time about XSL. In my experience the browser is quite poor at implementing other standards (e.g. CSS [Cascading Style Sheets]). Has this been other users' experience? It is particularly noticeable now that most other browsers are pretty good. It seems to be an odd version of the 80:20 rule, except in this case that 80 percent of users use the browser that is least standards compliant while 80% of browsers probably are. -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/>

3 2

Sharing and collecting examples, tools, techniques
by Daniel O'Donnell 25 Jun '04

25 Jun '04

A brief note thanking not only Peter Robinson but all participants for the willingness they have shown thus far to share techniques, tools, and examples with the list. It was exactly to get this kind of interchange that we set dm-l(a)uleth.ca up. We hope to collect these tips and tools as soon as the website is up, and encourage you to consider submitting project reports, notes, and research articles to the Digital Medievalist journal (about which more next week). I would also encourage those with questions to share those as well. The community of practice model suggests that questions--even quite basic questions--are very useful in fostering the development of a community's skills. The provoke others into considering techniques in new ways and foster the sharing of expertise. I hope to follow up our discussion of what we might want to see in a primer next week as well. -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/>

1 0

Re: [dm-l] Re: Experience using Microsoft's XSLT?
by Joris van.Zundert 25 Jun '04

25 Jun '04

Okay, let's get bickering ;-) (see your private mailbox). Joris >>> lou.burnard(a)computing-services.oxford.ac.uk 06/24/04 3:35 PM >>> Well, I apologise in advance for the fact that my impatience with Peter's (to my mind) ill-founded criticism of xslt risks opening up one of those utterly tedious arguments about whether language X is better or worse than language Y; particularly as I suspect such bickering is of minimal interest to most readers on this list. But just for the record, it seems to me rather strange to consider the "transformational" abilities of XSLT as somehow distinct from "the logical handling of data". XSLT is a language for processing structured data; which means it has to know about and usefully process data structures. You may wish to think of it as "just" a pattern matching language, or restrict its use in particular ways. But pattern-matching has wider applications than just document transformation. In particular, it is much less "procedural" than any of the other hybrid scripting languages you mention. However, we should probably have this argument in private! Lou . In message <s0daab4c.078(a)apps.niwi.knaw.nl> Digital Medievalist Community mailing list <dm-l(a)uleth.ca> writes: > I'm afraid mr. Burnard is slightly misinterpreting a popular IT-proverb. > It's not that there are good or bad programmers and programming > languages, but that there are no good or bad solutions, only more and > less adequate ones. > > As for programming languages: yes, there are bad programming languages > and XSLT is a good example of a bad programming language. Which it > actually should be, because XSLT was never meant as a programming > language, but as a template based transformational language for > transforming XML into XML or into representational forms like HTML and > not for logical handling of data. > > It's therefore very unfortunate that the XSLT 2.0 recommendation of the > w3c includes even more characteristics that are typical for programming > languages (like data types and logical structures). Rather XSLT 2.0 > should have confined the main purpose of XSL to where it's good at: > simple straightforward transformations of (chunks of) XML. > > Sophisticated and complex handling of data, structure and functionality > is more efficiently and adequately done or programmed in a robust > programming environment (like Eclipse), preferably in matured > programming languages (like Java or Python) using agile protocols. > > But that's all theory off course. In the real world XSLT will probably > become somewhat like, and as popular as hybrid languages such as PHP, > JSP and ASP. Such 'languages' just throw the whole bunch together: data, > data structure, logic, representation and functionality. Which seems > nice because it looks like you can do anything, fast. But in practice > such languages in the long run lead to unmaintainable code where the > boundaries between data and logic are unclear and portability and > interoperability become zero. It's all about separation of concerns and > responsibilities. > > It strikes me as rather strange that someone who very justifiably > promoted XML/TEI as a way to separate the concerns of meaning and form, > fails to see that XSLT does not do a very good job at this. > > y.s., > Joris van Zundert > > mr. Joris J. van Zundert (MA) > Researcher & Programmer, dep. of Dutch Literature and Linguistics > NIWI (Netherlands Institute for Scientific Information services) > > [visiting address] > Joan Muyskenweg 25 > Amsterdam > [postal address] > Postbus 95110 > 1090 HC Amsterdam > [phone] > +31 (0)20 462 86 47 > [fax] > +31 (0)20 665 80 13 > [e-mail] > joris.van.zundert(insert_an_at_sign_here)niwi.knaw.nl > [internet] > www.niwi.knaw.nl > > > > >>> lou.burnard(a)computing-services.oxford.ac.uk 6/23/04 18:20:47 >>> > > Peter, darling, you are talking nonsense. If you want a system based on > > words, mark up the words and XSLT will cope very well. (Yes, people do > > it: cf the BNC and many others). Likewise, if you want a system in > which > physical hierarchies matter, reflect that in your markup system. > > There are no good or bad programming languages: just good or bad > programmers. And designers. > > Lou > > > Peter Robinson wrote: > > > Well, let us start off with a little minor controversy. > > > > In the midst of converts to and enthusiasts for XSLT and that family > of > > tools, here is my two pennysworth. I suggest that a serious and > full-scale > > electronic edition of a typical medieval work, with the (now!) > standard > > requirement that it integrate text transcription/edition and images, > to a > > standard satisfactory for a scholarly user, cannot be made by these > tools > > from an XML base. > > > > There are two reasons for this. The first reason is that it seems to > me the > > fundamental requirement of such an edition is that it should present > a > > single page of a manuscript transciption alongside a single > manuscript image > > (or, in variants of this, a single column alongside the image, etc). > Given > > the standard XML architecture of these editions as these have > evolved, > > whereby textual divisions are set in the content of elements but > pages are > > marked with empty anchor elements (eg <pb/>) this is just what XSLT > etc find > > very tricky indeed. If you can do it (and I have not yet seen this > done, > > though I have heard lengthy explanations of how it *might* be done) > you can > > only do it with great difficulty with the standard tools. The problem > here > > is our old bugbear overlapping hierarchies, and XSLT etc just don't > have any > > easy answer to this -- and maybe no reliable answer at all. > > > > The second reason is to do with the nature of the XSLT programming > language > > and the kind of things we want to do with our displays, even in > situations > > where the problem of overlapping hierarchies does not hit us. Take a > single > > word in (for example) a line of transcription of a manuscript of the > > Miller's Tale. A reader might think: I would like to see what any or > all > > other manuscripts have at this word; I want to know whether there is > an > > editorial comment on the readings at this point; I would like to see > how the > > pattern of readings at this point maps against the overall pattern > of > > relationships among the manuscripts; I would like a lot of this > information > > held within the display so that just passing the mouse over the word > will > > pop up some of it. And I want this for every word in every > manuscript, and > > I want all this generated real fast for each page as I am impatient, > and I > > want quite a few other things too. Typically, this information is > scattered > > right across many different XML source files. It all has to be > fetched, > > amalgamated, sorted, served up for say some five hundred words on a > typical > > manuscript page, all in a microsecond. And also, for the programmer: > many > > things could go wrong in here, with all the conditional tests which > need to > > be made at each point and all the possible branchings the program > might have > > to take to cope with the messiness of manuscript life, so the > programmer > > needs a responsive and transparent programming environment, where it > is easy > > to diagnose what is going wrong, where, as the displays are built. I > sure > > would hate to try to do this in XSLT etc. While XML is fine for many > things, > > it does not look a great environment for programming to me. > > > > The question is germane because it now seems that a lot of effort is > going > > in to persuading humanities scholars, like us, that: > > A. we put all our data into XML, preferable the TEI variety > > B. we use XML programming tools like XSLT to get it to the reader > > I think the first proposition is unquestionably right: that battle > has been > > won. But XML's victory in the first does not mean that XML is the > right > > answer for the second. Indeed, I don't think it is. > > > > So, over to you all. I have set people this challenge before but here > it is > > again: someone, try to duplicate a typical single page say of our > Hengwrt > > Digital Facsimile from our XML source. And good luck to you. > > > > All the best > > Peter Robinson > > > _______________________________________________ > dm-l mailing list > dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l > > _______________________________________________ dm-l mailing list dm-l(a)uleth.ca http://listserv.uleth.ca/mailman/listinfo/dm-l

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 June 2004