Format and Content: Should they be separated? Can they be?: With a counter-example

Wendell Piez

Abstract

Conventionally, XML design and application methodologies propose that the format in which we create, store and maintain documentary data be isolated from the format of its presentation: this doctrine is usually designated as the “separation of format from content”, and the advantages of the layered architecture it implies are often cited as a compelling rationale for XML as a standards-based markup technology.

Yet experienced markup designers know that in practice, the separation is often more easily described than achieved, and that this design decision (like any other) involves tradeoffs. Those who are also students of poetry and art may bring some understanding of why: even a brief look at how “content” and “format” reflect and respond to one another in literary texts shows how problematic the insistence on their separation can sometimes be. In view of these difficulties, a recent project of the author's, WGLL (“Web Graphic Layout Language”), serves as a counter-example, showing how in certain application domains and operational contexts it is profitable to design a markup language with a confessedly presentational aim (even while attending to other requirements). WGLL is intended to be intermingled and mixed with SVG, a presentational format, in order to provide the SVG author full control over SVG output while reducing the tagging burden. In order to keep it both lightweight and transparent to the user, it makes sense that WGLL stay as close to SVG as it can. The resulting production architecture (straightforwardly implemented within a classic XSLT transformation framework such as Apache Cocoon) proves to have notable advantages of its own, even while it has to do without some of the benefits of the orthodox approach.

A consideration of what can and cannot be achieved this way sheds light both on the real practical advantages of distinguishing between format and content in our design, and on how this distinction is ultimately provisional, perhaps best asserted within the context of particular application requirements.

Keywords: SVG; XSLT; Markup Languages

Wendell Piez

Wendell Piez is a consultant at Mulberry Technologies, Inc. in Rockville, MD (USA). He is active in the Humanities Computing community through such organizations as ACH (the Association for Computing and the Humanites) and www.digitalhumanities.org. Both a practitioner and theorist in the design and development of markup languages and their applications since the mid-1990s, with broader interests in rhetoric and media theory, he has published and presented papers in several industry and academic venues, including Extreme and other IDEAlliance conferences.

Format and Content: Should they be separated? Can they be?

With a counter-example

Wendell Piez [Mulberry Technologies, Inc.]

Extreme Markup Languages 2005® (Montréal, Québec)

Copyright © 2005 Wendell Piez. Reproduced with permission.

True Ease in writing comes from Art, not Chance,
As those move easiest who have learn'd to dance.
'Tis not enough no Harshness gives Offense;
The Sound must seem an Eccho to the Sense.
Soft is the strain, when Zephyr gently blows,
And the smooth Stream in smoother Numbers flows;
But when loud Surges lash the sounding Shore,
The hoarse, rough Verse shou'd like the Torrent roar.
When Ajax strives, some Rock's great Weight to throw,
The line too labours, and the Words move slow....
[Pope 1709]

The fact that form and matter are connected in a work of art does not mean they are identical. It signifies that in the work of art they do not offer themselves as two distinct things: the work is formed matter. But they are legitimately distinguished when reflection sets in, as it does in criticism and in theory. We are then compelled to inquire as to the formal structure of the work, and in order to carry on this inquiry intelligently, we must have a conception of what form is generally....

[Dewey]

These citations are not here because this paper intends to pay close attention to these texts. But both, as commentaries, draw attention in their ways to an ancient distinction between “form” and “content” — a distinction that is reflected and reproduced in the XML design principle of separating “format” from content. This is an old fault line in criticism and the study of aesthetics and rhetoric. Proponents of the XML “separation of format from content” principle1 are often well aware that it echoes ancient dialogues, which postulate the same dichotomy (or an analogous one2) between “sound and sense” or “form and matter”, the “what” and the “how” of a text. Poets, artists and philosophers have been pondering this issue as far back as we care to remember. From this perspective, it may sometimes seem that the assumption that these poles can and should be separated — more, that achieving this separation is a self-evidently obvious and simple thing to do — is allowed too hastily, even naïvely.

We can take it for granted that the informed student of poetry, aesthetic philosophy, or the histories of these studies, will not necessarily reject the XML dogma out of hand, or even find reason to doubt its efficacy. Even if “format”, “content” and their separability (however we define these) are fictions of our own invention, these fictions become real and effective when a data processing system is built on them; nor should the student of poetry have any problem with this. Yet also, by reminding us of how problematic, at some fundamental level, the idea may be that information content should be distinguished and maintained separately from its format, poetry and aesthetics can also suggest to us where we will find the actual capabilities of our layered systems, and conversely of what we should not expect of them.

By way of contrast, a markup language designed by deliberately setting aside this core principle may help convince us that it is not universally applicable. WGLL (Web Graphics Layout Language, a project by the author to be presented here for the first time) is designed to support the easy authoring of SVG content, either for live presentation or for publishing on line. This tag set is deployed in a transformation architecture that makes it possible effectively to intermix WGLL into arbitrary SVG — thus allowing the combination of SVG's relatively free range of expression (as a fairly generalized display driver) with the ease-of-use features provided by a customized layer optimized (to the extent practical) for authoring. Rather than working at a separate layer from the SVG, WGLL elements are sprinkled into it, and its design seeks to help it “fit” into SVG rather than to isolate it in a distinct validation layer. Namespaces are used to distinguish the tag sets in use. This proves to be quite a practical design — for some purposes (fortunately including those that have motivated its development).

Recognizing the legitimacy of such an approach to tagging and markup language design can help us refine our sense of when and where a clear separation of layers is helpful and profitable. Consequently, we will also be able to design better systems, and to recognize good design when we see it without letting ideas (however good they may be in the abstract) get in the way.

Form, content, and their interpenetration

Consider this example of an English sonnet by John Keats:

If by dull rhymes our English must be chain'd,
And, like Andromeda, the Sonnet sweet
Fetter'd, in spite of pained loveliness;
Let us find out, if we must be constrain'd,
Sandals more interwoven and complete
To fit the naked foot of poesy;
Let us inspect the lyre, and weigh the stress
Of every chord, and see what may be gain'd
By ear industrious, and attention meet:
Misers of sound and syllable, no less
Than Midas of his coinage, let us be
Jealous of dead leaves in the bay wreath crown;
So, if we may not let the Muse be free,
She will be bound with garlands of her own.
Students of the sonnet tradition in English will recognize that this poem violates one of the structural rules of the form:3 that end-rhymes correspond (in one of several recognized ways) with arrangements of significant metrical line groupings of four or two lines (or six or eight): quatrains, couplets, octave and sestet. (The particular rules of sonnet form will not be explicated here; they are not hard to discover in any decent manual of prosody.) In this sonnet, octave flows directly into sestet and rhyming words spill between them. The resulting rhyme pattern, abcabdcabcdede, enacts the “garlanding” of rhymes it describes (particularly as contrasted to a more usual rhyme pattern such as abba abba cd cd cd or abba abba cde cde, as depicted in Figure 1).

Figure 1
[Link to open this graphic in a separate page]

A “rhyme plot” of the Keats sonnet shows how it varies from more conventional exemplars of the form. Of particular note is how many rhymes it has across the break (or “turn”) between its first eight lines (octave) and final six (sestet): there are no less than three, while no other sonnet diagrammed here (from a fairly representative sample) has even a single rhyme spanning the turn.

These diagrams are generated in SVG from XML source using XSLT. See [Sonneteer 2004] for more examples (an SVG viewer is required).

The variation of this example from the sonnet form is, of course, part of its point (even while it “formats” as a regulation sonnet). This sonnet does not “validate”: it fails one of the tests that help constitute it as a sonnet; yet this lapse corresponds precisely with the poem's message, which is basically to protest that the validation rules for English sonnets are too strict.4

The clear reflection between outer and inner form achieved by this poem, wherein what is said, and how it is said, are fused to the point where they can hardly be distinguished, makes it an extreme example, and it could be argued that it is hardly relevant to the task of the markup designer. Such testing, even breaking the rules, is what poetry is all about; but we are engaged in something more prosaic. Yet in other guises, this phenomenon of an apparent (even if momentary) “fusion of format and content” presents us with concrete issues that are faced by designers every day.

For example, consider the table of contents from Part II of a fairly conventional collection (at least with respect to its external form, its format) of related essays in prose by Marshall McLuhan, Understanding Media [McLuhan 1964] (see Figure 2). The markup designer (a role which can span the lines between tagger and content modeler) will see immediately that the titles of essays here follow a structural pattern: the author (McLuhan) names the essay's subject, and follows with a more suggestive statement of the essay's theme, working in counterpoint to the subject named. That these elements can be distinguished is confirmed by their appearance in the main text (see Figure 2, inset), where they appear typographically distinct from one another. Yet the consistency of their patterning — subjects like Press, Motorcar, Ads, Games, Telegraph, etc. — indicates that there is something more here than the usual title/subtitle distinction. Of twenty-six chapters, all but two name different media or media technologies, as if one could suppose a kind of “validation rule” here, by which this title/subtitle relation (or subject/theme, it may be) were enforced in each chapter heading. It's a kind of rudimentary index to the media the book promises to help us understand. Were we to have scores or hundreds of these essays, this distinction could be useful as well as interesting. Yet how to enforce the rule that “the title (or subject) must be the name of a medium”, especially when media here include such subjects as the clock, the motorcar, weapons and automation? (This discrimination could be done editorially, but current technology balks at it.) Format blurs into content, and the practical-minded designer of a tag set will sometimes curtail the ambition to do very much with the structure implicit here. Matters are only made worse by the fact that all this must be supposed to be happening below the renditional or presentational level as such (as is evidenced by the fact that a single chapter title is rendered two different ways on its two appearances). Our problem, that is, would not be solved by falling back on presentational tagging, since the presentation as such gives us even less information about what is “really happening” than would the conventional title/subtitle distinction. Probably in practice a markup designer would derive this table from titles held with each essay. How those titles are best modeled depends largely on the scope and variety of the kinds of titles that might appear.

The markup designer may or may never find a satisfactory way of dealing with this case in a real, not hypothetical, situation; in any case, she or he probably notices it. We recognize a correspondence and fitness, here and in similar such cases, between the implicit structure of the chapter headings, as manifested in their presentation, and their contents, the subject/theme pairings which in turn provides hints or indications of where the author (or at least, an editor or designer) is going. Moreover, this correspondence is exactly of the kind that we usually take to warrant (at least when it pervades a text), “descriptive” or “content-oriented” tagging in the first place. If nothing else, this example shows how there may always pop up, at least in texts of considerable interest, incidental structures in our text, which are in principle describable in a markup language, but which the descriptive system at hand — or any descriptive system not endlessly elaborated — has no direct provision to account for.5 At a certain level, most markup practitioners are used to such frustrations; for example, many tag sets in common use (for conference proceedings, for example) have no real provision for verse form. It may be that by turning up formal structures that are significant and that nevertheless evade any particular generic markup scheme (since no such scheme can account for all such incidental formal structures in advance), a sufficiently rich and interesting text will constantly demonstrate the limits of a scheme that tries to enforce the format/content separation. And this may be one of the deeper reasons why even the cleanest of descriptive schemes (such as Docbook or the TEI) may have a tendency to be “attracted” into application semantics, leaving the descriptive tagging behind as an implicit promise (at best) or pretense (at worst) while the actual goal (and hence, design in application) of tagging becomes oriented towards a particular processing outcome, no longer to “the text itself”.6

A counter-example: mixing layers in a markup language

To fall back on presentational or “procedural” tagging is not, of course, a solution to this problem, but rather a strategic avoidance of it. When text is encoded for presentation without regard to the implicit semantics of its formal structures — its “content” — it may be poorly suited for operations besides the strictly presentational (in their particular target technology). Yet if the examples in the last section suggest how even a well-designed, clean descriptive markup convention may fail, on occasion, to resolve structural and formal features of genuine interest and usefulness (which the human reader nonetheless has no difficulty discerning based on presentational cues, laborious though they may be to encode), likewise there may be times when (or applications where) such reliance on the reader might best be considered the norm, not the exception. To avoid observing a format/content distinction, in other words, might sometimes be a reasonable and effective strategy — and not just for the design of presentational formats themselves.

This seems to be the case with the author's experience with WGLL (Web Graphics Layout Language), a custom-built “add-on” to SVG. Of course, the question is not addressed whether this tag set is well enough designed (to say nothing of its specification, documention and packaging) to serve its purpose for any user besides the author, who has engineered it for his own use. But that unknowability aside, at least subjectively I can report what a great help it is to have a tag set that lightens the load of SVG creation. SVG has many strengths, but ease of authoring is not among them. (This is not untypical of presentational encoding schemes; the more control over presentation is offered, the more sophisticated has to be a user interface for authoring. And for whatever reason, tools for authoring for SVG have been slow to come.)

In early experiments along these lines7 I did tend to follow a purist doctrine of separation, designing an entirely separate tag set from which to derive the SVG documents I wanted.. But as I used the technology I was creating, increasingly I found myself stitching together, by hand, the results of such operations (SVG created by transforming XML source) with one another and with arbitrary SVG. When I shifted the production architecture from a discrete batch process onto a web platform (Apache Cocoon), thereby shortening the loop between authoring and production,8 it became clear how this headache could be eased (if not cured altogether) by allowing any SVG to appear — indeed, to make SVG by default the document format assumed — with elements intermingled, in my “WGLL” namespace, designed to provide support for the specific authoring tasks I was facing, and for which I wanted help. Once this line had been crossed, it became immediately apparent what virtues there were in keeping the design of WGLL as close to SVG as possible. RelaxNG and Namespace Routing Language, plus judicious use of Schematron, could provide for validation of the resultant compound SVG+WGLL, as necessary; but as with procedural systems in general, the “validation” will ultimately be in the process, in this case in the transform that renders WGLL into SVG and the subsequent rendering of the result in an SVG application (a two-stage process that could be made transparent by calling the web platform).

A straightforward XSLT transformation architecture proves to be well-suited for this arrangement. There is one single major respect in which this XSLT differs from the usual: by default, XSLT strips from the source document any node structures not matched by templates provided, leaving only the text content without adornment. In this case, however, SVG elements themselves are considered as content, to be passed through unchanged, by means of an identity transform. For an author already fairly familiar with SVG, this has the result of providing transparency: I can include any SVG I want. But where special assistance can be provided by using customized WGLL tagging, I can use that too.

Figure 3
[Link to open this graphic in a separate page]

Authoring WGLL is easier than authoring arbitrary SVG, since the SVG encoding of common design elements can be largely automated though a stylesheet. This is not in itself different from the assistance provided by any generic tag set, say, to the generation of HTML or PDF output, except that the design of WGLL is kept close to the design of SVG itself, to reduce cognitive dissonance when they are used together (as they are intended to be).

WGLL supports both reusable visual elements and event-driven behavior such as linking and “flashing” (hiding and showing groups of figures in response to mouse-clicks). A library of common “widgets” can thus be offered, and the most repetitive, tedious and difficult coding tasks can be reduced or eliminated (or more precisely, provided by the stylesheet, as derived by the logic encapsulated in WGLL elements). An example of WGLL coding appears in Figure 4.

Figure 4

<w:frame id="greyblack"
  background-color="gainsboro" background-opacity="0.4"
  border-width="1" border-color="black" border-opacity="0.6"/>

<w:hide id="contrast" x="200" y="260"
  show-when="maintitle.click" hide-when="contrast.click">

  <w:panel x="0" y="0" width="280" frame="greyblack"
      padding="12" font-size="14" line-height="20"
      font-family="serif" font-color="black">
    <w:line font-style="italic"
      line-height="14" font-size="20">What's Easy</w:line>
    <w:line font-family="sans-serif">
      <a xlink:href="XMLchrysanthemum">simplicity at the center</a>
    </w:line>
    <w:line>XML, XPath, XSLT</w:line>
    <w:line>publishing (web, print, on demand)</w:line>
    <w:line>interfacing information systems</w:line>
    <w:line>reaching the world</w:line>
  </w:panel>

  <w:panel x="300" y="0" width="240" frame="greyblack"
      padding="12" font-size="14" line-height="20"
      font-family="serif" font-color="black">
    <w:line font-style="italic"
      line-height="14" font-size="20">What Isn't</w:line>
    <w:line font-family="sans-serif">
      <a xlink:href="complex-edges">complexities at the boundaries</a>
    </w:line>
    <w:line>choosing technologies, partners</w:line>
    <w:line>fitting the pieces together</w:line>
    <w:line>the piece you haven't learned yet</w:line>
    <w:line>staying out of the rabbit hole</w:line>
  </w:panel>

</w:hide>
          

<xsl:template match="wgll:hide">
  <g style="visibility:hidden"
    transform="translate({(@x,0)[1]} {(@y,0)[1]})">
    <xsl:copy-of select="@id"/>
    <set attributeType="CSS" attributeName="visibility" to="visible"
      begin="{@show-when}" fill="freeze"/>
    <set attributeType="CSS" attributeName="visibility" to="hidden"
      begin="{@hide-when}" fill="freeze"/>
    <xsl:apply-templates/>
  </g>
</xsl:template>

<xsl:template match="wgll:panel">
  <xsl:variable name="frame" select="key('by-id',@frame)"/>
  <xsl:variable name="width" select="@width"/>
  <xsl:variable name="padding" select="@padding"/>
  <xsl:variable name="height"
    select="(sum(for $line in child::wgll:line return
      $line/ancestor-or-self::*[@line-height][1]/@line-height) )
            + ($padding * 2)"/>
  <g transform="translate({@x} {@y})">
    <xsl:copy-of select="@font-size | @font-family | @font-style"/>
    <rect width="{$width}" height="{$height}"
      fill="none" stroke-width="1">
      <xsl:apply-templates
        select="$frame/(@background-color | @border-color |
          @background-opacity | @border-opacity | @border-width)"/>
      <xsl:apply-templates select="@background-color | @border-color |
          @background-opacity | @border-opacity | @border-width"/>
    </rect>
    <xsl:apply-templates/>
  </g>
</xsl:template>

<g id="contrast" style="visibility:hidden" transform="translate(200 260)">
  <set attributeType="CSS" attributeName="visibility" to="visible"
    begin="maintitle.click" fill="freeze"/>
  <set attributeType="CSS" attributeName="visibility" to="hidden"
    begin="contrast.click" fill="freeze"/>
  <g transform="translate(0 0)" font-size="14" font-family="serif">
    <rect width="280" height="138" fill="gainsboro" stroke-width="1"
      fill-opacity="0.4" stroke="black" stroke-opacity="0.6"/>
    <text x="12" y="26" font-size="20"
      font-style="italic" fill="black">What's Easy</text>
    <text x="12" y="46" font-family="sans-serif" fill="black">
      <a xlink:href="chrysanthemum">simplicity at the center</a>
    </text>
    <text x="12" y="66" fill="black">XML, XPath, XSLT</text>
    <text x="12" y="86" fill="black">publishing (web, print, on demand)</text>
    <text x="12" y="106" fill="black">interfacing information systems</text>
    <text x="12" y="126" fill="black">reaching the world</text>
  </g>
  <g transform="translate(300 0)" font-size="14" font-family="serif">
    <rect width="240" height="138" fill="gainsboro" stroke-width="1"
      fill-opacity="0.4" stroke="black" stroke-opacity="0.6"/>
    <text x="12" y="26" font-size="20"
      font-style="italic" fill="black">What Isn't</text>
    <text x="12" y="46" font-family="sans-serif"
      fill="black">complexities at the boundaries</text>
    <text x="12" y="66" fill="black">choosing technologies, partners</text>
    <text x="12" y="86" fill="black">fitting the pieces together</text>
    <text x="12" y="106" fill="black">the piece you haven't learned yet</text>
    <text x="12" y="126" fill="black">staying out of the rabbit hole</text>
  </g>
</g>
          

[Link to open this graphic in a separate page]

Shown here are (a) a sample of WGLL source code, (b) a couple of relevant templates from the stylesheet that converts this to SVG, (c) the SVG result of the transformation, and (d) an excerpt from the resulting display.

The idea here is to allow the author to control anything in the SVG she or he needs to, without having to be burdened with tedious and repetitive tagging chores, most particularly those associated with reusable design elements such as insets, callouts, and simple hypertext or animation widgets. The two WGLL elements whose templates are shown here provide for formatting and layout and also for some dynamic behavior: the panel element draws a box and lays lines of text out onto it, calculating the height of the box dynamically based on the lines it contains (their count and line-heights). panel elements may refer to frame elements to provide for some of their formatting attributes such as border and background color. (This level of indirection could have been provided through CSS; by doing it this way, properties can be bundled and named.) The hide element allows a set of grouped elements to be hidden or revealed in response to mouse-clicks from the user, using SVG declarative animation; since this presentation logic is encoded in the stylesheet, the author does not need to know exactly how to configure the animation, but can simply “declare its declaration” at a higher level.

The XSLT-literate reader will also notice that these routines make use of XSLT and XPath 2.0.

In this context, WGLL's approach to modeling is minimalistic, aiming for the least possible tagging necessary to achieve the most general results in the SVG, while addressing its primary requirement, namely to hand authoring in generic XML tools). This coordination-by-design with the presentation layer has the advantage of allowing the user (me) to work on authoring layer as if the two were unified. While requiring some care to keep the two layers distinct, but coordinated, this reduces cognitive confusion and the extra mental work of tracking both levels at once, and together.

This approach requires an entire different design strategy for a tag set from the usual (a double-sided content- and requirements-oriented document analysis). Only a few elements with very general capabilities, like panel (“draw a box and write some lines of text in it” or picture (“call in an image and scale it, looking up its dimensions if necessary”) are actually needed, since the criterion for introducing an element is no longer the presence of a distinguishable structure in a set of source documents (extant or prospective), but only its immediately evident usefulness. Because I can use old-fashioned SVG in my WGLL whenever I wish, the design can afford to be jealous. This also has an implication for the design process, which can be much more bottom-up than the classic top-down analysis. Design and implementation can be driven much more by the “scratch where it itches” principle; they do not have to be anticipated so clearly and comprehensively. The resulting lightweight tag set provides the user with a vernacular that allows the simple design and easy deployment of structures which, in their SVG rendition, are nonetheless more complex than one would ever want to code by hand.

In defense of the separation: layered system as medium

While an approach like WGLL to SVG authoring proves to work very well for its purpose — providing the open-ended features of arbitrary SVG, while lightening the authoring burden — it does have shortcomings which will not surprise the advocate of generic markup systems, and which can illuminate why the separation is often useful.

In fact, much as one might expect, it turns out WGLL's shortcomings are in exactly those capabilities recognized as strengths of more descriptive encodings, such as versatility and reusability of the encoded data. Strong “descriptive” schemes often come with side-applications, or are fairly easily fitted to them, even unexpectedly. Logical structure can be leveraged to support various helpful features in display and navigation (although WGLL can provide cues for generating navigation structures as well). Sources map more easily to multiple media formats. Content-oriented validation (for quality checking or any other reason) is easier to engineer and scale. And finally, the system may be found to be relatively robust and insulated from the vagaries of the marketplace, as various presentational formats evolve and obsolesce over time. In some areas (such as indexing, metadata, navigation or hypertext), well designed procedural code can include a surprising amount of “descriptive” logic; what it typically needs help with is validation. But it is hard to imagine it serving all these various requirements as well as a cleanly-separated descriptive layer.

But a deeper understanding of the trade-off comes only when we bring to mind the conceptual roots of the orthodox layered system. Splitting a publishing system into presentational and logical layers is in essence (as I have described elsewhere [Piez 2001]) an application of the principles of division of labor, specialization (called in some contexts separation of concerns, the MVC paradigm, or any of several other codifications) and interchangeability (as afforded by standardized interfaces) as applied to electronic text. Far from being radically new (they are radical, but not new), these principles permeate in our culture, underlying the development of industrial and post-industrial manufacturing systems and providing the foundation of our commoditized, consumer-oriented economy. Indeed, when they work well in real-world publishing environments, electronic systems often roughly replicate (even while they shake up and reorganize) established channels and lines between the roles of author, editor, copy editor, layout designer and so forth. This correspondence has a deep reason: automation itself, at every level of its operation (and computer technologies are built of stacks of such automating layers), is based on the abstraction of formal process away from material medium, which is in effect what we have been talking about all along: in this respect there is a likeness between a modern industrial plant in which machine parts are fabricated and assembled to given sets of specifications, and a descriptive markup language, which provides similar top-down control, transparency and efficiencies of scale to an information processing system. The dilemma here is really none other than the problem faced by Henry Ford when he announced a customer could have a car any color they liked as long as it was black.9 And of course, media technologies have been pushing the boundaries of achievable automation since Gutenberg and before.

A markup language that serves only to “drive the browser”, hearkens back to craft work — this is not so much a Model T or even an automobile, but an engine shop where any manner of car, bike or light aircraft might be developed, tested and tried. SVG and HTML, and perhaps XSL-FO, any of these could be treated as we treat SVG here, fitting it with a kind of “extension kit”. Seen in this view, it appears that the stress here is that between considering each instance as a separate creative work expressive of the intent of the author(s), versus considering the system as a whole, encompassing schemas, stylesheets and user interfaces as well as the instances that flow through them, as a creative work, (and as such) expressive of the intent of its designer(s).10 It may be clearer in this context why a project like WGLL can be effective at least on a small scale, and at that level — supporting “boutique” projects rather than assembly lines — might provide a better fit for problems immediately at hand than a more strictly separated and layered language.

A designer of markup languages is both hemmed in by lines (in our case these are drawn by the constraints of XML itself), and scoring one, drawing a set of distinctions between what is mine and what will be held relatively unyielding to me. Whether as artist, design committee member, diligent employee or desperate hacker, a designer of markup languages is similarly etching for others (for anyone who has to work downstream) lines that are hardly erased, erecting walls that cannot be moved, furnishing hallways whose edges and corners will become all too familiar. These lines may be described, in shorthand, as between “content” (yours) and “format” (theirs). That the open specification of markup languages is a political as well as an economic issue has always been understood by the proponents of standards-based technologies in this arena. That it has to do with fundamental tradeoffs at the level of the design of digital media themselves, as forms of expression, has perhaps been less well understood, even when we have felt it.

Which part is mine to control, shape and form, and where have I accepted limitations? The question in itself is near to the essence of art, and no secret to artists. Markup language design is interesting and provocative exactly because it simultaneously masks, and promises (or forecasts) the representations to be constructed in and by our automated systems. The forecast (the “inferences licensed by the markup” 11) is more or less direct, more procedurally-oriented or more “descriptive”; in either case it is an art of enabling. This suggests that since a pragmatic account is available for descriptive markup, we have no particular need for an absolutist metaphysical argument, such as is often (though not always) implied by the doctrine of separation: that descriptive or content-oriented tagging is somehow closer to the “essence” or “idea” of the document. Descriptive encoding may gesture toward the noumenal, while never really escaping the phenomenal it distances itself from. But in doing so, it does not so much touch the essence or true nature of the text— it certainly does not capture or circumscribe it — so much as present a theory about it or reading of it (12). This theory may be very useful, when applied with some rigor. It may even be artful, and often is. But it does not have to presume to be the final word. And experienced practitioners may find the more pragmatic argument more compelling in any case.

Figure 6
[Link to open this graphic in a separate page]

Introducing a layered system for the production of digital media provides many advantages for scaling, application design and management, and long-term maintenance. But it doesn't actually take us closer to the “truth” of a text.

Interestingly, this unchaining from a pretense of representing the noumenal or ideal essence of a text actually liberates descriptive markup to do what it does best. Keats' poetry (or at other extremes, the arts of Hakuin, or Dali or the students of Dali who paint his likeness on the art museum steps) are simultaneously material creations, and something beyond that: artists do not merely cast their works into forms, they also reinvent the forms they cast into, by the very act of expressing themselves through the formal structures they create. A markup language is both such a creation in its own right, and a means for further expressions in concrete media (even if a medium as evanescent as projections onto a screen): as such, it may be an art more like architecture, landscaping, interior or furniture design, than like sculpture or flower arrangement. For some writers, being asked to write in a descriptive encoding scheme must seem like being an actor, who is given the strings of a marionette theater to pull, when what he really wants is to walk out onto the stage. Yet others know that marionette theater can be an expressive medium of beauty and power.13

Because Keats worked in a medium designed for mass production (the press of his day), and therefore within a fairly well-defined set of expectations for presentation and formatting, his works convert relatively painlessly into online digital media, which are themselves an expression of mass standardization in several layered markets (for software, hardware, infrastructure, distribution channels, typography, visual design, book design, literacy), and a direct descendant of his press. In this as well as in other ways, the design of markup for digital media shows itself to be a direct heir of that great art of invisibility, typography, with its even deeper roots in poetics and visual design. Markup does not have such a close relation to other arts, which accordingly translate with less fluency to the electronic realm (however digitizing may benefit them in other ways); some of them arguably reach altogether beyond the bounds of what markup languages can practically describe. Yet images and sounds, or the stroke of a brush, are not less artistic than a Keats poem. They are merely different. And even in the case of Keats, while it is not hard to mark up Keats to format “transparently” in an HTML page (though it is arguably harder than it should be), it is hard to imagine the markup language that could mark up everything in it we might find of interest (even if merely “formally”). In light of this variety of forms and expressions, it appears that the truly noumenal is accessible through our material creations despite our best efforts to escape them. There is no reason to fear or disdain presentation-oriented design. We need only to discriminate when we want and need an isolated layer for our information capture, and when we want to work more directly with the “hot lead”.

Figure 7
[Link to open this graphic in a separate page]

The stairway leading to the front entrance of the Philadelphia Museum of Art, April 15 2005. Because the vantage is not perfect, we can see the painter winking (not as photographed). Photograph by the author.

Figure 8: Hakuin's motto
[Link to open this graphic in a separate page]

Some might suggest that given how many removes this rendition is from the original painting (this is scanned from a print made of a photograph of the original), it can only carry a fraction of the original's power. (Assuming poetry is in some way like electricity, each of these “transformations” steps down the voltage.) Such “vitalist” notions aside, even so far removed the message here is strong and unmistakable even to the reader who knows no Japanese: the single character for center enacts the statement of the poem without hesitation, and sufficiently for the purpose, with only the barest words necessary to indicate the sense. [Stevens 1993]

Notes

1.

This design principle is so deeply embedded in XML (both the practice and the literature on it) and in SGML before it that any list of citations of it must be partial. “Classic” formulations of the idea can be found in [Coombs, Renear, DeRose 1987], [Interleaf 1994] and [St Laurent 1998]. An excellent (if implicit) critique of the idea can be found in [Hillesund 2002]. The most comprehensive and subtle discussion of the principle may be that of Alan Liu [Liu 2004].

2.

Interestingly, Dewey's “matter and form”, as they apply to plastic arts such as sculpture, may be seen as reversing what we think of as “format and content”. His “matter” is not “subject matter” but material, meaning stone or bronze, or ink on paper or the letterforms made in ink on paper or pixels on a screen: what we mean by “format”. His “form” must then be what we call “content”, which in the case of markup languages is presumably (or usually) the textual content, which in turn is related to signification and (arguably) communicative intent, and indeed in representational or abstract plastic arts, the “content” is visual form, shape and color.

3.

The keen-eyed may notice the slippage here between my discussions of “format” and “form”. Of course these terms are not fully interchangeable. The interesting thing about the word form is that it can stand for what is on either side of the “format/content” divide. Rather than take up this philosophical problem now, however, I hope the reader can agree that whatever form and format are, they are of a whole: at the very least, they reflect one another ? and that an English sonnet might enact some transgression over a form (format) vs content divide. The important thing here is to see that there is a reflection, not to assert (a metaphysical question) what it is that reflects in what.

4.

In fact this sonnet is so pure a formal demonstration that it diminishes into being about nothing but itself. (The greatest sonnets are also about a subject. This one does little more than gesture at the larger world.) Yet this itself is a tradition in sonnets (other self-describing sonnets are to be found throughout the tradition by authors as various as Spenser, Shakespeare, Wordsworth and Frost) — so even in its setting itself apart, this sonnet is following a tradition, varying a gesture that has been made before.

5.

This could be a corrolarry to Gödel's theorem, I suppose. The frequently-observed potential for semantic markup of elements to be rendered in tables is probably the way in which this conundrum is most often presented to working markup practitioners. Yet while almost any table might be up-converted to a more usefully descriptive, content-oriented tagging, the cases where there are enough such tables representing a single type of dataset to reward this level of effort may be more few and far between; and one has to draw the line somewhere. Sneaking the semantics in through the use of such devices as HTML class or CALS/OASIS/Docbook name attributes (allowed on table rows or columns) is a compromise, providing at least for the harder part of the job, at the cost of not being easily validatable by machine-checking.

6.

Some markup designers may never have anything else in mind, of course. Nor should the intent of users be constrained always by a designer's intent. This is merely to point out a gap between what we are actually achieving and what we promise to achieve.

7.

For example, see [Piez 2004]

8.

Since Cocoon supports dynamic transformation on the server, it can provide a working environment as close to “WYWSIWYG” as one is likely to want with an XML/XSLT production framework. One edits the file in the filesystem and then browses it through Cocoon, which handles all the intermediate processing. This is not dissimilar from what is provided by client-side transformations, except of course that no SVG Viewers currently provide for SVG created dynamically in this way.

9.

But see http://www.ahooga.com/info/black.shtml on this story — the actual truth of which (other colors of body paint were disallowed when they were found not to dry quickly enough) goes to demonstrate the point.

10.

But check out http://books.nap.edu/html/beyond_productivity/ch2_b1.html: “The idea of mass-produced one-of-a-kind products — postmodern manufacturing — is possible because one talented individual can bridge the worlds of engineering and consumer aesthetics, and because the technology exists to do so. In the process, the creative professional’s role becomes more abstract. It is less about designing objects, and more about designing the process that makes the objects, including the parameters that transcend the designer’s direct control. The end result conflates the uniqueness of handcraft with the scale of industrial production.”

11.

A formulation of Sperberg-McQueen, Huitfeld and Renear to describe the way in which markup works, on the way to formalizing its semantics. [Sperberg-McQueen et al., 2000]

12.

Markup “reflects a theory of the text” is also a formulation of C.M. Sperberg-McQueen. Not dissimilarly, literary critical theorists of various persuasions have stressed the origins not only of criticism but also of poetry and art, in reading.

13.

See Heinrich Kleist's essay on the marionette theater, on line at http://www.thealit.de/lab/LIFE/LIFEfiles/r_07_1.htm (English translation, by Thomas G. Neumiller, at http://www.english.emory.edu/DRAMA/KleistMarion.html).


Bibliography

[Coombs, Renear, DeRose 1987] Markup Systems and the Future of Scholarly Text Processing. First printed in Communications of the ACM 30 (November 1987); 933-47. On line at http://xml.coverpages.org/coombs.html (April 14 2005).

[Dewey] John Dewey, Art as Experience. 1934. Perigee Books: 1980.

[Hillesund 2002] Terje Hillesund. Many Outputs — Many Inputs: XML for Publishers and E-book Designers. Journal of Digital Information, Vol 3, no 1. 2002-08-06. On line at http://jodi.ecs.soton.ac.uk/Articles/v03/i01/Hillesund.

[Interleaf 1994] Interleaf Corp. 1994. The SGML Guide. On line at http://xml.coverpages.org/ileafgd.html (April 14 2005)

[Liu 2004] Alan Liu. 2004. Transcendental Data: Toward a Cultural History and Aesthetics of the New Encoded Discourse. Critical Inquiry 31 (2004): 49-84. On line at http://www.uchicago.edu/research/jnl-crit-inq/features/artsstatements/arts.liu.htm (August 15 2005)

[McLuhan 1964] Marshall McLuhan. Understanding Media. 1964. Cambridge: MIT Press, 1994.

[Piez 2001] Wendell Piez. Beyond the Descriptive vs Procedural Distinction. Extreme Markup Languages 2001. Available on line at www.piez.org/wendell/papers/beyonddistinction.pdf.

[Piez 2004] Wendell Piez. Way Beyond Powerpoint: XML-driven SVG for Presentations. Presented at XML 2004 (November 2004). On line at http://www.idealliance.org/proceedings/xml04/papers/156/piez-xml2004-ideadb.html.

[Pope 1709] Alexander Pope. Essay on Criticism. 1709.

[Sonneteer 2004] Wendell Piez. The Sonneteer. August 2004. On line at http://sonneteer.xmlshoestring.com (April 14 2005).

[Sperberg-McQueen et al., 2000] Sperberg-McQueen, C.M., Claus Huitfeld and Allen Renear. Meaning and interpretation of markup. Markup Languages: Theory and Practice. Vol 2, no 3 (2000): 215-234. Version on line at http://www.w3.org/People/cmsmcq/2000/mim.html

[St Laurent 1998] Simon St Laurent. XML: A Primer. IDG Books Wordlwide / MIS Press: 1998.

[Stevens 1993] John Stevens. Three Zen Masters: Ikkyu, Hakuin, Ryokan. Tokyo: Kodansha International, 1993.



Format and Content: Should they be separated? Can they be?

Wendell Piez [Mulberry Technologies, Inc.]