GeneticEditionDraf1Comments

Section 3.2: In what sense is chapter 10 of the TEI Guidelines not a "thorough manuscript description" whereas HNML is?

Section 4.0: I confess to once proposing the use of groups of changes in the Wittgenstein manuscripts. Whenever I found a simple case that could be grouped (which was rarely) I put it in, but the editors always took it out. Why? Because you can't group changes much at the markup level. The hierarchy you introduce by doing that soon breaks down in practice. Genetic texts aren't hierarchical.

Genetic relations "between different parts of the text, within a single document and across several documents" cannot be expressed at all efficiently in markup. Even if you could encode it somehow using, say, links, what is going to be the user interface? You should specify that too, because if you can't use it, it may as well not be there.

Section 4.1: So we have a strict hierarchy: document->writing surface->zone->line. What about changes in the margin that cross "zones", arrows connecting text in different "zones", underlining and crossing-out that spans "zones" etc etc? Not only that but zones "can be nested and grouped". Handwritten documents unfortunately don't have a hierarchical structure. Not at all. Elli Mylonas in 1996, wrote: "We now know that the breaking of strict hierarchies is the rule, not the exception". And Alan Renear in 1997: "Whatever may be said for hierarchy as a tendency, it does not seem to be, even in its perspective-contingent form, an essential aspect of textual structure." If anything has been learned in the last 20 years using markup to encode literary documents it is that.

Section 4.4: How exactly are you going to collate texts in XML? If you produce an apparatus criticus of an XML text you will get unmatched tags in the footnotes. Then you will have to take out the tags to process it, so why encode it in XML in the first place?

Section 4.4.3: How do we make markup comment on itself? There is no clean way, except by using hacks.

Section 4.4.4: "The re-alignment of the transposed blocks or segments can be supplied via a stand-off mechanism" I very much doubt that this is possible. Firstly if blocks can be transposed willy-nilly they are either well-formed or not well formed. If not well formed (as is usually the case) you can't define and transpose them in this way. If well formed the schema of the document cannot permit simple chunks of well-formed XML to be shifted around the document and placed wherever is required by the transposition. You can also have transposition of markup, e.g. the moving of a line-break. Standoff techniques are mostly used in corpus linguistics texts that are unchangeable. In a humanities text you must be able to edit the text, that means redefining the standoff information if you use byte offsets and at least having to be careful if you use word elements with ids. The latter approach is not easier because it obscures the text with a flood of mostly useless markup codes. Why are current techniques for representing transposition in markup so bad? Because it's not possible to do any better.

Section 4.5.1: This seems to rely on interlinking to connect elements in the hierarchy by another, non-hierarchical path. Firstly, there is blind faith here that encoding the features somehow in markup will solve the problem. But you have to prove that you can compute it. You can't compute an arbitrary network of links. Try to solve the Travelling Salesman Problem instead. It's probably easier. Secondly, how many humanists would willingly work with such a complex system of markup as you propose here?