dm-l

dm-l@uleth.ca

2786 discussions

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

Open Access
by Klaus Graf 25 Jun '04

25 Jun '04

><http://www.blackwellpublishing.com/book.asp?ref=1405103213&site=1> >(Unfortunately, this one will cost about $150, but perhaps you can >convince >your library to purchase it.) > I do not appreciate such suggestions. There is not only a journal prices crisis but also a crisis for scholarly monographs. I know that most authors would like to answer: Oh, that's bad but I am not responsible for the book prices ... Feel free to read an article on Open Access for scholarly editions in German at http://archiv.twoday.net/stories/230198/ Klaus Graf -- http://archiv.twoday.net/topics/English+Corner/

4 3

RE: [dm-l] Useful free tools for finding unicode characters
by Binkley, Peter 24 Jun '04

24 Jun '04

Another very useful Unicode reference is the EKI database: http://www.eki.ee/letter/. As well as helping navigate through Unicode and other encodings, it has a nice function to show what happens if you take a text encoded in one system and convert it to another. 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

1 0

RE: [dm-l] Re: Manuscript-transcription correlation
by Binkley, Peter 24 Jun '04

24 Jun '04

It seems to me that Peter Baker has indicated the real value of XSLT in this context: that it can be used for on-the-fly presentation or preprocessing, as appropriate. The real limited resource in this kind of work is not storage space or processing capacity but my ability to learn new languages. Since this is an area where the scholars are also building the tools, it makes a lot of sense to keep the toolkit as simple as possible. Peter > -----Original Message----- > From: Peter Baker [mailto:psb6m@virginia.edu] ... > But if a thing has got to perform fast, it might be best to > use the XSLT > to create static pages or a database, or turn data from a > database into > pages, rather than have it dynamically create pages from a large > underlying text. > 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

1 0

Re: dm-l Digest, Vol 1, Issue 3
by Carol Pasternack 24 Jun '04

24 Jun '04

I'm thinking about working on a project a year or two from now that involves a ms facsimile, edition, etc., but in the meantime I would like to know what issues to think about before I get started such as what factors help determine what framework to set up or what software to use. I don't want to do a whole bunch of work on something and then discover that I made less than favorable decisions and have to redo a bunch of tedious work. So, I am looking forward very much to learning from the primer and from lurking on this list about important concerns and solutions. I suspect I will have much better questions later in the process. Carol Braun Pasternack English Department University of California Santa Barbara, CA 93106-3170 --On Wednesday, June 23, 2004 7:02 PM -0600 dm-l-request(a)uleth.ca wrote: > Send dm-l mailing list submissions to > dm-l(a)uleth.ca > > To subscribe or unsubscribe via the World Wide Web, visit > http://listserv.uleth.ca/mailman/listinfo/dm-l > or, via email, send a message with subject or body 'help' to > dm-l-request(a)uleth.ca > > You can reach the person managing the list at > dm-l-owner(a)uleth.ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dm-l digest..." > > > Today's Topics: > > 1. Re: Re: Experience using Microsoft's XSLT? (Peter Boot) > 2. Re: Re: Experience using Microsoft's XSLT? (Lou Burnard) > 3. Re: Re: Manuscript-transcription correlation (Peter Baker) > 4. [dm-l]: Overlapping Markup SIG (WAS Experience using > Microsoft's XSLT?) (Dorothy C. Porter) > 5. Re: Re: Experience using Microsoft's XSLT? (Martin Holmes) > 6. What every digital medievalist should know? (Daniel O'Donnell) > 7. What would people like to see in a primer and/or series of > primers? (Daniel O'Donnell) > 8. Fonts (Patrick Conner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 Jun 2004 19:30:42 +0200 > From: Peter Boot <pboot(a)xs4all.nl> > Subject: Re: [dm-l] Re: Experience using Microsoft's XSLT? > To: Digital Medievalist Community mailing list <dm-l(a)uleth.ca> > Message-ID: <40D9BE42.6000202(a)xs4all.nl> > Content-Type: text/plain; charset=us-ascii; format=flowed > > >> 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. > > At the Constantijn Huijgens Instituut we have done this (more or less). > Our edition of the 'Geraardsbergse handschrift' (Geraardsbergen > Miscellany) is based on a TEI encoded XML file where text structure is > used to define the hierarchy, and pages are encoded as pb-elements > (milestones). Nevertheless, we present our edition on a page by page > basis. > > The edition is available at > http://www.chi.knaw.nl/epub/mvn/geraardsbergen/index.html. I'm afraid > everything is in Dutch right now, but from the 'Inleiding' > (introduction) option, the xml and xslt source files are available. The > edition pages can be accessed from the 'editie' (edition) or 'inhoud' > (contents) option. On some pages (e.g. > http://www.chi.knaw.nl/epub/mvn/geraardsbergen/f109r.html), there's also > a facsimile. > > (We'll create full facsimile-cum-transcription editions in the future; > this one is a book based publication, converted into digital form > recently). > > In the present edition, performance is not an issue, as the pages > contain static html. If I were to write this stylesheet again, in the > interest of performance and clarity, I would separate the milestone > handling from producing the final output. I'd use an intermediate > stylesheet to transform the milestone elements into full page elements > at the highest level of the hierarchy. These page elements would contain > those segments of the text, div, p (etc.) elements that the associated > page contains. The resulting XML file, would, I'm sure, perform > beautifully in a dynamic environment. > > Peter > > > ------------------------------ > > Message: 2 > Date: Wed, 23 Jun 2004 18:55:51 +0100 > From: Lou Burnard <lou.burnard(a)computing-services.oxford.ac.uk> > Subject: Re: [dm-l] Re: Experience using Microsoft's XSLT? > To: Digital Medievalist Community mailing list <dm-l(a)uleth.ca> > Message-ID: <40D9C427.7030907(a)computing-services.oxford.ac.uk> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Martin Holmes wrote: > >> I think Peter's point is a very good one, though; in XML, one must >> prioritize one hierarchy over another where they overlap; if the >> conceptual structure is prioritized, the physical must be relegated to >> milestones. >> >> I think there is a long-term solution to this. I think multiple markups >> can exist on the same text, as long as they're in "different >> dimensions"; it's hard to explain, but imagine the text as a string >> going through space, and the markups as planes radiating out from it. > > [... snip ...] > > That's right. You can have multiple annotations on the same XML > structure. This technique, now generally known as "stand-off" > annotation, is currently quite popular in the field of linguistics, to > handle things like prosodic vs syntactic hierarchies. You segment your > text once, and then you create as many different views of it as you > like. Each view constitutes a single hierarchy, and is composed of > pointing elements which identify how the fragments of your segmented > texts are to be combined in that particular hierarchy. Something like it > is described in the chapter of the TEI Guidelines which addresses the > issue of non-hierarchic structures. > > Your Shakespeare is pretty neat, by the way! How does one get to see the > XML source though? > > Lou > > > > ------------------------------ > > Message: 3 > Date: Wed, 23 Jun 2004 13:56:58 -0400 > From: Peter Baker <psb6m(a)virginia.edu> > Subject: Re: [dm-l] Re: Manuscript-transcription correlation > To: Digital Medievalist Community mailing list <dm-l(a)uleth.ca> > Message-ID: <40D9C46A.3000700(a)virginia.edu> > Content-Type: text/plain; charset=UTF-8; format=flowed > > The task Martin wants to perform is exactly the kind of thing that XSLT > is good at and could do easily. > > I also see Peter's point, echoed here. Until we have a markup language > that handles overlapping hierarchies natively, all proposed solutions > will be annoying in some way. Still, I have a higher opinion of the > abilities of XSLT than Peter does (I've been using it in font > development, of all things, so I look at it as pretty flexible), and > I'll bet it could handle the XML workarounds for overlapping hierarchies > such as the one proposed in the paper by Alexander Czmiel linked to by > James Cummings. > > But if a thing has got to perform fast, it might be best to use the XSLT > to create static pages or a database, or turn data from a database into > pages, rather than have it dynamically create pages from a large > underlying text. > > Peter Baker > > Martin K. Foys wrote: > >>> At 08:49 AM 23/06/2004, Peter Robinson wrote: >>> > 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. >>> >> >> I have not worked with XSLT, so this might seem like a naive question, >> but is it possible to write a bridge program to copy text from a >> specific starting tag to an ending tag, create a new file for just >> that text, and then display that file next to the MS image? >> ~ Martin Foys >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Martin K. Foys >> Assistant Professor >> Department of English >> Hood College >> Frederick, MD 21701 >> >> vox: 301~696~3740 >> fax: 301~696~3586 >> ether: foys(a)hood.edu >> >> Bayeux Tapestry Digital Edition: http://www.sd-editions.com >> >> _______________________________________________ >> dm-l mailing list >> dm-l(a)uleth.ca >> http://listserv.uleth.ca/mailman/listinfo/dm-l >> >> > > > > ------------------------------ > > Message: 4 > Date: Wed, 23 Jun 2004 15:01:30 -0400 > From: "Dorothy C. Porter" <Dorothy.Porter(a)uky.edu> > Subject: [dm-l]: Overlapping Markup SIG (WAS Experience using > Microsoft's XSLT?) > To: dm-l(a)uleth.ca > Message-ID: <1088017290.2158fb40Dorothy.Porter(a)uky.edu> > Content-Type: text/plain; charset="UTF-8" > > Hello All, > > At last year's Text Encoding Initiative (TEI) Member's Meeting, I (along > with Peter Robinson, and Patrick Durusau of the Society for Biblical > Literature) convened a Special Interest Group on Overlapping Markup > issues. We haven't done very much since then, unfortunately, but Patrick > and I are slowly working on a web page that will highlight various > different approaches to dealing with overlapping markup and conflicting > hierarchies. I'll post an announcement here when the page goes live - > it's good to see that folks are so interested in this problem! > > There is also an overlapping markup listserv, to join go to > http://listserv.brown.edu/tei-ol-sig.html. (Also, if you're interested in > reading the report from last year's meeting, you can find it here: > http://www.tei-c.org.uk/Activities/SIG/Overlap/olm01.txt) > > Many thanks to Daniel et. al. for putting this listserv together! > > Dot Porter > > > *************************************** > 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 > *************************************** > > > ------------------------------ > > Message: 5 > Date: Wed, 23 Jun 2004 12:14:03 -0700 > From: Martin Holmes <mholmes(a)uvic.ca> > Subject: Re: [dm-l] Re: Experience using Microsoft's XSLT? > To: Digital Medievalist Community mailing list <dm-l(a)uleth.ca> > Message-ID: <6.1.1.1.0.20040623120952.01d9cec0(a)pop.uvic.ca> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > Hi there, > > At 10:55 AM 23/06/2004, you wrote: >> Content-Transfer-Encoding: 7bit >> >> Martin Holmes wrote: >> >>> I think Peter's point is a very good one, though; in XML, one must >>> prioritize one hierarchy over another where they overlap; if the >>> conceptual structure is prioritized, the physical must be relegated to >>> milestones. >>> I think there is a long-term solution to this. I think multiple markups >>> can exist on the same text, as long as they're in "different >>> dimensions"; it's hard to explain, but imagine the text as a string >>> going through space, and the markups as planes radiating out from it. >> >> [... snip ...] >> >> That's right. You can have multiple annotations on the same XML >> structure. This technique, now generally known as "stand-off" >> annotation, is currently quite popular in the field of linguistics, to >> handle things like prosodic vs syntactic hierarchies. You segment your >> text once, and then you create as many different views of it as you >> like. Each view constitutes a single hierarchy, and is composed of >> pointing elements which identify how the fragments of your segmented >> texts are to be combined in that particular hierarchy. Something like >> it is described in the chapter of the TEI Guidelines which addresses >> the issue of non-hierarchic structures. > > Sounds like exactly what I was thinking of. Do you know what kind of > markup tools are used to edit texts in this way? > > >> Your Shakespeare is pretty neat, by the way! How does one get to see the >> XML source though? > > If you "View Source", you'll see something like this: > > <docroot href="AWW_F_ISE.xml"></docroot> > > where the href is the actual markup document. I use the "wrapper > document" as a way to avoid hard-coding the XSL stylesheet into the > original markup. The markup in this case is a proprietary system created > by Mike Best, the prof involved, but TEI versions of the markup have > subsequently been generated from it. > > Cheers, > Martin > > ______________________________________ > Martin Holmes > University of Victoria Humanities Computing and Media Centre > mholmes(a)uvic.ca > martin(a)mholmes.com > mholmes(a)halfbakedsoftware.com > http://www.mholmes.com > http://web.uvic.ca/hcmc/ > http://www.halfbakedsoftware.com > > > > ------------------------------ > > Message: 6 > Date: Wed, 23 Jun 2004 13:46:52 -0600 > From: Daniel O'Donnell <daniel.odonnell(a)uleth.ca> > Subject: [dm-l] What every digital medievalist should know? > To: dm-l(a)uleth.ca > Message-ID: <40D9DE2C.5020806(a)uleth.ca> > Content-Type: text/plain; charset=us-ascii; format=flowed > > As part of our (coming) website, we are thinking of including working > paper, guidelines, project reports, etc. Something I'd like to see is a > version of Jim Marchand's What Every Medievalist Should Know (WEMSK) on > medtext for scholars working with digital media. Obviously "a primer for > working with computers" is too broad; but perhaps some kind of topic by > topic discussion of important issues one should know about. > > Does anybody know of a good community-focussed digital primer that might > serve as a model (e.g. perhaps aimed at teachers or some similar group)? > This idea is still in its early stages. My preference would be for > something developed through the community as a whole. > > -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/> > > > > > > ------------------------------ > > Message: 7 > Date: Wed, 23 Jun 2004 16:14:25 -0600 > From: Daniel O'Donnell <daniel.odonnell(a)uleth.ca> > Subject: [dm-l] What would people like to see in a primer and/or > series of primers? > To: dm-l(a)uleth.ca > Message-ID: <40DA00C1.6050209(a)uleth.ca> > Content-Type: text/plain; charset=us-ascii; format=flowed > > I've had a couple of off line responses to my question about a primer. > This might be a good opportunity for participants at all levels of > expertise to mention the types of thing they wish they knew (had known) > in starting or completing various projects. > > It is important in a community like this that members not feel > intimidated about raising simple questions or problems as well as > complex or advanced. Don't be afraid to say what you think for the list > as a whole! > > Cheers. > -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/> > > > > > > ------------------------------ > > Message: 8 > Date: Wed, 23 Jun 2004 21:01:57 -0400 > From: "Patrick Conner" <pconner(a)wvu.edu> > Subject: [dm-l] Fonts > To: <dm-l(a)uleth.ca> > Message-ID: <s0d9efd1.074(a)WVUGW01.wvu.edu> > Content-Type: text/plain; charset=US-ASCII > > . . And damned fine fonts they are. > > I'm hoping that, down the line, Peter, you'll keep us up to date on > here regarding unicode and other font development. Can you tell me > whether MS-Word in its newest Macintosh iteration can run Junicode > smoothly? > > --pat > > Patrick W. Conner, Director > West Virginia University Press > P.O. Box 6295, West Virginia Univ. > Morgantown, WV 26506-6295 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Voice: 304.293.8400 x491 > Fax: 304.293.5380 > Email: pconner(a)wvu.edu > Web page: www.wvupress.com > >>>> psb6m(a)virginia.edu - 6/23/04 1:56 PM >>> > [cut] > > Still, I have a higher opinion of the > abilities of XSLT than Peter does (I've been using it in font > development, of all things, so I look at it as pretty flexible), and > I'll bet it could handle the XML workarounds for overlapping > hierarchies > such as the one proposed in the paper by Alexander Czmiel linked to by > > James Cummings. > > [cut] > > Peter Baker > > Martin K. Foys wrote: > >>> At 08:49 AM 23/06/2004, Peter Robinson wrote: >>> > 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. >>> >> >> I have not worked with XSLT, so this might seem like a naive > question, >> but is it possible to write a bridge program to copy text from a >> specific starting tag to an ending tag, create a new file for just >> that text, and then display that file next to the MS image? >> ~ Martin Foys >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Martin K. Foys >> Assistant Professor >> Department of English >> Hood College >> Frederick, MD 21701 >> >> vox: 301~696~3740 >> fax: 301~696~3586 >> ether: foys(a)hood.edu >> >> Bayeux Tapestry Digital Edition: http://www.sd-editions.com >> >> _______________________________________________ >> 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 > > > ------------------------------ > > _______________________________________________ > dm-l mailing list > dm-l(a)uleth.ca > http://listserv.uleth.ca/mailman/listinfo/dm-l > > > End of dm-l Digest, Vol 1, Issue 3 > **********************************

1 0

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