Humanist Discussion Group, Vol. 32, No. 483.
            Department of Digital Humanities, King's College London
                   Hosted by King's Digital Lab
                       www.dhhumanist.org
                Submit to: humanist@dhhumanist.org




        Date: 2019-02-22 06:07:50+00:00
        From: "C. M. Sperberg-McQueen" 
        Subject: SGML and the taint of printers ink (or:  what technologies are whispering to us)

> In Humanist 32.478, Desmond Schmidt writes:
>
>> What this seems to imply for me is that print editions are *best*,
>> and that seeking for an archetype using a scientific method is the
>> hallmark of what makes a great digital edition also.
>
> I'll let Hugh Cayless speak for himself, but it may be worth pointing
> out that print has been used for many different kinds of editions, and
> not solely for editions which seek to restore the authorial or at
> least the archetypal text.
>
> Printed scholarly editions may or may not be best kind of scholarly
> editions, but they have occupied the attention of a good many fairly
> smart people for going on for five hundred years.  Some of what has
> been said about them has indeed (as Desmond Schmidt correctly
> observes) been unduly colored by characteristics of the print medium
> -- or of particular book production practices.  My favorite antagonist
> in this regard is Thomas Tanselle's long essay on critical apparatus,
> which conflates the particular book production techniques he knows
> best with the intrinsic nature of scholarly editions and critical
> apparatus.  Desmond Schmidt is right that we should not take guidance
> uncritically from print editions.  But I think we *should* learn what
> we can from them, and I think we can learn a lot.
>
>> I actually think the digital medium calls into question the whole
>> idea of "rigour".
>
> Here I part ways with DS, though it's not clear whether we have a
> substantive difference of opinion or only a difference of opinion
> about the denotation of the word "rigor".
>
>> The requirement that only one version of a text could be represented
>> drove the whole design and method of print.  The immense changes
>> brought about by digital media: from stable->ephemeral,
>> immutable->flexible, expensive->cheap, lifeless->interactive must
>> have a profound effect on what makes a good digital edition.
>
> The first sentence is *almost* true.  That is, it's true that a lot of
> what one reads about what a scholarly edition "must" or "should" do is
> actually based on the assumption that such an edition "must" present
> only one text (or so it has always seemed to me -- again, Tanselle on
> apparatus is a good example).  Of course, that assumption was false in
> print as well as being false in electronic editions -- there are
> plenty of print editions which print multiple texts of the same work
> -- but digital editions seem to make the point clearer to people,
> since in digital editions the cost of paper, ink, and binding is no
> longer the limiting factor.  (Alas, it then turns out that the cost of
> editorial work often takes its place.)
>
> I think the second sentence is likely to be true, and that we
> currently have only the dimmest understanding of what those changes
> mean or how to use them for purposes of learning.  We live in an
> incunabular age -- not just in the sense that we are at the beginning
> of what we may expect to be a long history of electronic editions (if
> humanity lives long enough) but in the sense that a few hundred years
> from now our electronic editions and their presentation software
> (assuming they are still accessible to users) are likely to seem as
> strange and difficult to use as we find incunabula without title
> pages, page numbers, running heads, and the other features we use to
> structure pages and books.
>
>> I don't think it should just be a copy of a print edition that is
>> "*better* for being digital".
>
> I don't take Hugh to have advocated that digital editions copy
> anything from print editions but their thoroughness, their careful
> construction, and their intellectual seriousness, so if I'm right in
> seeing here an implicit suggestion that this sentence is disagreeing
> with Hugh, I disagree with that suggestion.  But I agree that digital
> editions which are "just" copies of print editions, in roughly the
> spirit of PDFs made available on the Web, are a bit disappointing.  (I
> don't want to overstate the case here, or look gift horses in the
> mouth.  PDF versions of print editions are in fact more convenient
> than the print editions in some ways -- I cannot travel with multiple
> volumes of the Leibniz edition, but I do have access, when I travel,
> to multiple volumes, thanks to the generosity of Leibniz's editors and
> their publisher.  And it's easier to do string searches in PDF than in
> a paper edition.  But I hope for more from electronic editions.)
>
>> And to counterpoint your assertion that this is the strength of TEI,
>> I think it is actually its weakness: historically a print system of
>> hierarchies, nested headings, chapters, paragraphs, and formats gave
>> rise to tagging systems: the elements and attributes are actually
>> the old functions and parameters of explicit print instructions
>> (e.g. .indent 10) that gradually evolved into "generalised"
>> markup. Go back in time step by step and you will see that it is
>> so. So print is still embodied in GML->SGML->XML.
>
> Since DS and I have disagreed earlier in this thread about the history
> of SGML, XML, and TEI, I should perhaps say explicitly here that DS is
> right to observe here that much (though not, perhaps, all) of the
> driving force in the development of descriptive or generic or
> generalized markup did indeed come from people involved with
> typesetting, either as vendors or as customers.  Their attitude toward
> print seems to me more complex than some people realize at first --
> perhaps because they did not regard the material properties of a given
> print presentation as intrinsic to the text (after all, they might
> change the presentation radically in the next release of the system).
> But yes, one of the things the creators of SGML and XML wanted to do
> with texts was produce attractive print products from them.
>
> One of the things that distinguishes SGML, however, from ODA (the
> Office Document Architecture, a rival ISO spec) or Scribe or TeX or
> LaTeX -- let alone from word processors -- was that the developers of
> SGML wanted it to be possible to do *more* than produce print from
> SGML documents.  They made something of a design principle of the idea
> that they did not have an exhaustive list of the things people might
> want to do with documents, and that the meta-language they were
> developing needed to be able to handle things other than print.
>
> When the TEI project started, Lou Burnard and I were tasked, as
> editors, with deciding whether SGML could in fact be used as the basis
> for the TEI's scheme of scholarly text encoding.  When we started
> attending SGML-industry events to learn about SGML, in order to make
> that decision, more than one member of the responsible ISO working
> group said to us things like "Wow! you really exist!  We predicted
> you!  We were sitting in that godforsaken conference room in [some
> city with an international airport] arguing about [some clause or
> other in the spec], and [someone] said 'There may be people who want
> to do -- I don't know what -- they might want to mark up the text with
> linguistic analysis!  They have to be able to use this feature.' And
> you do really exist, and you want to mark texts up for scholarly work.
> Wow."
>
> Given that the developers of SGML made a conscious effort at
> generality, it seems ungracious to dismiss SGML as intrinsically
> inappropriate merely because we think it is tainted with the stench of
> printers ink and traces of typesetter's lead.
>
> And quite apart from questions of human interaction, it's an egregious
> error to evaluate any technology solely in terms of what we think its
> developers wanted to achieve instead of what the technology they built
> actually does and does not to.  Having some idea of what they were
> trying to do can be helpful, but whether they succeeded or failed, the
> product of their work may (or may not) be useful for other things as
> well.
>
> It is possible, for example -- I have not asked those who were there
> -- that empty elements were introduced in SGML solely for the purpose
> of marking things like the point of insertion of images or tables or
> figures stored externally.  But once the syntax supports the notion of
> empty elements, those empty elements can be used to mark any kind of
> point we choose, including the start and end of regions that we choose
> not to tag as single SGML elements, or which we cannot tag as single
> elements because they don't nest.  The intention of the designer is no
> longer relevant here -- the intentional fallacy is fallacious not only
> in the interpretation of literary texts but also in the interpretation
> of technology.
>
> The TEI defines a number of special-purpose empty elements to mark
> boundaries in alternative hierarchies, as well as a generic
> 'milestone' element.  The Open Scripture Information System spec
> generalizes the idea of such elements and uses them to provide
> convenient solutions for nesting problems that arise in the encoding
> of Biblical texts.  A manuscript project I was involved in generalized
> the idea a bit further and uses mixtures of empty elements and
> conventional content elements to encode three intertwined hierarchical
> structures in manuscript transcriptions (full account in my Balisage
> 2018 paper).  We are not bound by or limited to the motivating use
> cases of empty elements. We are bound by what made it into the
> specification.
>
> The same argument applies to the concurrent-markup feature of SGML.  A
> member of the WG once told me (the exchange is probably still findable
> in the archives of comp.text.sgml) that CONCUR was intended to be used
> for things like recording both a 'logical' structure and a 'physical'
> structure for documents, so that a single SGML document could be used
> both as a 'revisable-text' document (which would have internal
> representations of things like sections, paragraphs, and headings) and
> a 'final-form' document (which would have page and line breaks).  But
> CONCUR is not defined in terms of a logical and a physical hierarchy
> (it could have been -- ODA was, for example), or even in terms of
> allowing either one or two hierarchies.  CONCUR was designed with what
> I have always thought of as a blind devotion to generality -- it
> allows the user to select or specify which hierarchical structures to
> use, and how many, even though the WG apparently really saw no reason
> for more than two.  So CONCUR can in principle be used for things like
> marking both the metrical hierarchy and the dramaturgical hierarchy of
> verse drama.  (That was the example I used that got Charles Goldfarb's
> interest -- he was convinced that hypertext was the right way to
> handle problems like that, though I never fully comprehended how he
> thought that should work.)
>
> [I will note in passing that CONCUR turns out to have its own
> challenges, ably enumerated twenty-odd years ago by Murata Makoto in
> an article whose citation I do not have to hand.  My point is not that
> CONCUR is perfect but that any technology may be usable in ways that
> go beyond, or contradict, the intentions of its creators.]
>
>> If we truly want to make *digital* editions we have to get off the
>> train and hire a scooter, and go where we want, not to where the old
>> technology tells us we must keep going.
>
> I agree with this in principle, though it's clear that DS and I hear
> different messages when we attempt to make out what any given
> technology is telling us.
>
> ********************************************
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> cmsmcq@blackmesatech.com
> http://www.blackmesatech.com
> ********************************************
>



_______________________________________________
Unsubscribe at: http://dhhumanist.org/Restricted
List posts to: humanist@dhhumanist.org
List info and archives at at: http://dhhumanist.org
Listmember interface at: http://dhhumanist.org/Restricted/
Subscribe at: http://dhhumanist.org/membership_form.php

Editor: Willard McCarty (King's College London, U.K.; Western Sydney University, Australia)
Software designer: Malgosia Askanas (Mind-Crafts)

This site is maintained under a service level agreement by King's Digital Lab.