I recently gave a talk on a panel sponsored by the Digital Arts and Humanities Working Group at The Ohio State University regarding my XML-based composition class, and I thought it worthwhile to post the script here on HASTAC. The talk is largely a synthesis of ideas I've introduced in previous blog entries, hopefully more coherently in this iteration.
Knowing only that they had signed up for English 1110.01, first-year writing, my students walked into the classroom for the first time to see projected on the front screen what I’m currently projecting now. While many of the students weren’t familiar with the exact nature of XML, they all could infer its status as a coding language. I’m sure that a rush of runic symbols arranged in a cryptic, illegible syntax flashed before many of their eyes like an oracle’s vision of impending ruin, and I don’t begrudge them the sentiment. Unable to include any indication on the general course catalogue of the nature of the format and design of my particular section of first-year writing, an otherwise common GEC requirement for which curricular variations normally are restricted to thematic focus, I attempted to make lemonade when life gave me lemons—that is, to employ the shock value of discovering the XML format to lead students to think critically about the rhetorical situation from day one. As Evan Donahue argues in his response to Matthew Kirschenbaum’s “Hello Worlds: Why Humanities Students Should Learn to Program,” “students should learn to program, but they should not let their inability to program prevent them from engaging with the computer sciences,” which, Donahue clarifies, explore similar problems with different discourses. Donahue admittedly qualifies a few of Kirschembaum’s points while agreeing with his overall argument, which I read from the standpoint of the rhetorical analysis: the primary or core concern in the first-year writing class. Kirschenbaum recalls lamenting that his undergraduate programming classes treated code as procedural and vocational and lacked any engagement with questions about “why programming was a unique and startling way of looking at the world; why it was, in fact, a kind of world-making, requiring one to specify the behaviors of an object or a system from the ground up; why and how such an activity was connected to the long traditions of humanistic thought…What was lacking, in other words, was any kind of historical and intellectual context for why ‘bubble sorts’ and ‘do-while loops’ mattered.” In place of historical and intellectual context, I would point to code’s value as both a tool and a subject for rhetorical analysis. To rephrase slightly, both my argument today and the idea to which I attempted to lead my students during our first class meeting is, simply, that both code and the act of coding are deeply rhetorical.
As reinforcement, my course theme—the individual focus that each first-year writing instructor must choose for his or her section—is “Codes,” the full description of which I’ve just projected now. Initially pointing to examples of DNA and digital technology, I quickly turn to the insight (a la Donahue) that “[b]eyond science and programming, codes are everywhere.” Beyond demonstrating the wide berth that I’ve given students in terms of choosing a primary source as the focus of their semester-long research project, the litany of examples points to the rhetorical nature of codes. Many of my students’ initial reactions to discovering the course format leads us to think about codes in terms of legibility and audience: that a code—whatever it may be—unavoidably includes and excludes, invites and alienates particular audience groups based on an assumed literacy of the code itself. Additionally, however, code also is constitutive; in other words, it makes something, which I read as analogous to Kirschenbaum’s advocacy of using code to model objects. By making something, code also makes an argument about what can and should make that thing. As Kirschenbaum elaborates, “virtual worlds are empirical, but they are not objective. They embody their authors' biases, blind spots, ideologies, prejudices, and opinions. That is not a liability but their great asset, allowing them to serve as platforms for propagating some particular view of reality.” To make the argument that a student paper should be divided into paragraphs does not strike us as particularly problematic or complex view—or perhaps it does, if we’d like to go down that road. However, the argument that a student paper should include an introduction that should include a thesis statement does strike us as productively debatable, which leads us to ask questions about the rhetorical situation: why should this type of writing be formed in this way? what are the benefits of that form? how might it be used most successfully? for whom, for what audience does this form seem designed? beyond audience—or, perhaps qualifying our sense of audience when it comes to class assignments—how might each assignment’s particular goals for the writer affect our understanding of the code that should constitute the assignment?
“Programming is about choices and constraints, and about how you choose to model some select slice of the world around you in the formal environment of a computer,” Kischenbaum contends, and it was my sense of this clearly rhetorical conception of coding and programming that led me to conceive of my current course design. At the most basic level, what distinguishes the course as experimental is a shift in the medium of composition: from word processing programs—the staple media of the vast majority of most electronic composition today—to <oXygen/>, an extensible markup language (XML) editor. Put simply, students compose their assignments in XML. Moreover, they all work on a single corpus file housed in an online version control repository. A useful analogy here is the filmstrip of negatives. If the XML corpus file is that filmstrip, each student’s “section” is one box, or one negative. Of course, in the XML file, students’ boxes continue to grow downward into increasingly long rectangles, and for certain activities (peer review, for example) students compose not in their own boxes but in their colleagues’. Before working on any portion of their work, students “check out” the most recent version of the XML file from an online storage location, and after adding and/or editing their work, they update the XML file once more before “committing” the complete set—both their changes and the most recent version of the file—back to the online repository. Calling back to my previous comments regarding the constitutive rhetoric of codes, my very conception of the course format implies a code that makes an argument about what should constitute the first-year writing class. Drawing from the goals of the first-year writing program, my design constitutes the first-year writing class as (a) the merger of composition and metacognition, and (b) the practice of radical transparency, by which all students can see what others are doing at any given moment. I intend for the course design to promote collaboration and teamwork so that students think of themselves as colleagues who can teach and learn from each other. Additionally, the corpus file, which in one location centralizes all student work, from daily to major assignments, encourages students to think of their day-to-day efforts as a concerted effort to achieve the intellectual goals of the course.
The constraint of composing in XML, I would argue, is what out Director of First-Year Writing calls an “enabling constraint.” Forcing composers to describe or make explicit their rhetorical and compositional choices, to define what they’re doing as they’re doing it, the XML editing software renders metacognition, or the reflection on one’s own thought processes, as one and the same with composition, the act of typing words on the computer screen. XML is a purely descriptive language: it does not tell the computer what to do with the information that it contains. It is, in Kirschenbaum’s terms, entirely “human readable.” Enclosing text in descriptive tags structured like Russian dolls, one inside the other inside the other, composers have the freedom to name any part of their text anything that they want, and they can name any part of their text as many different things as they want. Should they want to tag their thesis statements as hippopotamuses, they can. Should they want to tag their thesis statements fifty times over as fifty different kinds of animals, they can. Of course, this isn’t terribly useful, and the XML editor that my class is using, as another enabling constraint, requires descriptive markup complaint with the Text Encoding Initiative, or TEI, which seeks to standardize markup so that XML can be human readable not only to the one particular human who composed it, but also to other humans. XML markup can be broken down into three pieces: the element, the attribute, and the attribute value. Elements form the basic markup tags, such as “p” for paragraph or “title” for title. An element can have as many attributes as are TEI compliant with it. Attributes further describe elements. For example, the “xml:id” attribute allows the composer to assign a unique identifier to an element, and the “type” attribute allows the composer to categorize the element. The third part of XML, the attribute value, is simply the value assigned to the attribute. In this case the composer has the most freedom, and can assign any useful value to attributes. What’s important, though, is that the attribute values are uniform throughout the entire XML document. Beyond making explicit their rhetoric and compositional choices in the XML editor itself, students can then employ those tags to transform their compositions in many ways. This is where I come in, as well as does the germ of the title of my talk today.
By “transforming composition,” I mean to convey both ideological-figurative and practical-literal significations. Writing in extensible stylesheet language, or XSL, I tell the computer what to do with the XML tags that otherwise would mean nothing to it. The standard view of an assignment lends itself as an obvious candidate. Thus, we go from something that looks like this to something that looks like this. Fortunately, this is not the only transformation, or “view,” that students may employ to reflect on their work. Here we see a breakdown. Returning to the notion of constitutive codes as rhetorically contingent on the goals of each assignment, we see that others contain different tags that then are filtered out and highlighted in the analysis section of the HTML readout. The transformations, then, indicate what an author understands to be a useful or relevant way of viewing the composition. Students can view their evolving thesis statements over several assignments. They can view everyone’s thesis statements (or thesis statement breakdowns) for a particular assignment. They can view all images that they have collected but that are divided among several assignments. They can view peer and instructor comments as superscripted and hyperlinked footnotes and as pop-up text when the mouse pointer hovers over the superscript notation. As a final example, I’ll briefly cover the revision exercise that I recently had my class complete.
In most cases, students learn revision as the deletion of a “bad” passage in favor of the addition of a “better” passage, privileging the revised version so much that the previous versions are literally erased. Out of sight, out of mind. Thus, conceiving of revisions as alternate versions of a single text becomes difficult, as does conceiving of revision as a prolonged and continuous engagement with the text. However, the Text Encoding Initiative protocols that <oXygen/> requires us to use describe revision as the creation of parallel versions of a text. Using a textbook reading on revision (which can take us only so far), I had groups revise a sample student paper for the same assignment that they themselves were about to submit. I previously had entered the paper into the XML corpus file that contains all student work (and other associated information for the class) with the bare minimum of markup. In small groups, students were assigned sections of the sample paper and told to discuss what they would revise (and why) were it their own writing. They applied the following markup. Thus, students indicated each revision point as a choice between the original version and their revised (regularized, according to TEI) version. Multiple revisions can be nested in each <choice> element. Revision therefore loses a lot of its deterministic aura (“my writing was bad but now it's good”) and students conceive of revision less in terms of correctness and more in terms of rhetoric: how different ways of articulating an idea come across to an audience.
Moreover, we can examine the implications of the markup as descriptors. <choice> is pretty accurate as far as I'm concerned; it doesn't imply preference. However, to call one version "original" and the other "regular(ized)" does imply preference, which may lead to the kind of "incorrect/correct" or "bad/good" dichotomy that I meant to eschew in my teaching of revision. In Debates in the Digital Humanities Amy Earhart’s chapter examines the cultural and political implications of recording certain linguistic content as <sic> and <corr>, or, in other words, "as such" and "correct." <orig> and <reg> seems to bring up the same issues, though perhaps with less bluntness as calling something "correct." I intentionally avoided <sic> and <corr> as the nested content of the <choice> elements precisely for the problematic implication that revision is correction and not versioning. There are other ways to code variant readings of a text that have since been brought to my attention, but the point here is that viewing the code as rhetorical rather than merely procedural reveals its great benefits for the first-year writing class. Designing and teaching this class has been a deep meditation on the nature and purpose of writing courses, and, while I’m aware of no other attempt to teach a writing course in this way, I hope that my efforts represent only the tip of the iceberg when it comes to taking advantage of the rhetorical and compositional affordances and constraints of a diverse array of media and software. As of earlier today the corpus file has been edited 860 times and is approximately 24,500 lines long [at the time of this blog post it has been edited over 1100 times and is 35,000 lines long]. The students who are doing this work are nothing short of pioneers; after learning of the unique course design, none dropped the class, and all have been game for the unfamiliar. I have booked a room to host an open house event for the students to talk to interested graduate students, faculty, and staff about their work. The response to the event, so far, has been humbling.