Balisage Paper: The Concrete Syntax of Documents: Purpose and Variety

Separate the presentation from the structure.

As I type these words in an XML format in which font, layout, and indentation choices do not appear, it is clear this is not a novel observation. Even in the much more presentation-focused HTML world, a great deal of the presentation is usually separated into CSS rules. Setting aside ordering (and in some cases even that), a W3C XML Schema or Relax NG Schema can be seen as defining abstract syntax rules for a document. True, there is also a conventional concrete syntax for an unrendered structured document: the XML form. This makes the claim confusing. Is it not a concrete syntax specification, then? Where XML is the abstract syntax and the XML document is its rendering, yes. Where the formatted document of some specific kind is its rendering, no. The form of this document that would appear on the Balisage web site: this is the concrete syntax form of the document whose abstract syntax rules are defined by the Balisage tag set schema.

Run rules both ways.

Up-conversion from a concrete document to well-structured XML is a process of undoing the rules at all levels. In practice this also requires uncovering what those rules are in the first place. This is most of what makes it difficult. The other part that makes it difficult is notations that do not work well as a system, or that have a lot of ambiguity. Documents in these notations can be (and are) misinterpreted by human beings also, but human beings are more clever than programs, and more adept at bringing to bear common sense reasons to prefer one interpretation over another.

Nevertheless, I believe it is helpful to regard the problem of up-conversion as fundamentally a parsing problem combined (perhaps) with a rule discovery problem.

Language versioning is a form of language translation.

The entire vexed discussion of namespace versioning and XML schema versioning speaks agreement to this point. Try as you might to plan for it or minimize it, some changes to vocabularies are breaking changes, and must be treated in some ways as a new language.

Language versioning entails transformations and the application of new rules.

The same is true in the XML world, where (a concrete representation of) the structured form holds primary. Putting that document in a new language version means transforming that document. XSLT suits this purpose admirably.

Use an abstract syntax specification that distinguishes rules that would manifest in the structure from rules that allow better organization of the grammar itself.

Such mechanisms as DTD parameter entities, XML Schema named groups, type inheritance, and substitution groups and the abstract elements that go with them accomplish some of the same goals.

Separate the type of abstract syntax unit from its (named) role within its parent construct.

One could write XML Schemas using only local elements and named types to get close to this. The case relation (the role) would be captured by the local element name, and the structural kind would be captured by the type name. Unfortunately, the type name is not manifest in the abstract syntax representation, and following this pattern interferes with the ability to use substitution groups to provide for organizational classes. The idea that each piece of an abstract syntax instance has a manifest named role distinct from the name of that non-terminal is absent.

Where the XML stack needs to target components of a parent, it relies on parent child XPath match patterns perhaps with position counters (in XSLT) or CSS selectors (in CSS). Adding metadata through attributes can reclaim the distinction. CSS classes are often used to provide role information. Sometimes other attributes are used instead, or as well.

Should XML element names name kinds of things or roles of things within a larger entity? The debate rages, and vocabularies are inconsistent. Being able to consistently name both aspects would be helpful.

Separate concrete syntax into distinct mini-rules.

Both CSS and XSLT provide for the ability to define separate rules for pieces of a larger construct. This enables a great deal of their flexibility.

Presentation order relates closely to layout across space, and for non-lists is an aspect of concrete syntax.

In the XML stack, XSLT can be used to output in an order distinct from the underlying order in the abstract syntax, but ordering is clearly taken as part of the abstract syntax. Reordering is seen as a transformation effect, not a rendering effect.

Where order is fixed, a specific ordering conveys no information. Since the order is known in advance, additional presentation marks are not required to tell you which subcomponent is which. Where order is free, every specific order conveys specific information. Since the order could be anything, other presentational marks are required to keep subcomponents straight. As such, ordering is intrinsically bound up with other presentational devices, just as word order in natural language is intrinsically bound up with morphological devices.

Failing to treat it that way leads to adding pointless flexibility and complexity to content models, or pointless complexity and the need for transformations in order to render properly, to the detriment of all.

Bootstrap from a self-describing meta-grammar.

The W3C XML Schema for schemas is self-describing, but neither the stack as a whole nor other pieces of it are. While this is a handy property for getting systems off the ground, testing their efficacy, and for accommodating changes to them, it is by no means crucial.

Presentation widgets have a purpose: to convey specific abstract syntax relationships. Knowing the purpose of presentation widgets allows for analysis of a notation as a whole.

This is the key to designing better notations (by which I mean to include rendered documents in general) and to recover the structure of such concrete rendered documents.

Separate the abstract geometry from concrete geometry.

Various presentational effects can be analyzed as the fracturing of an abstract geometric space due to the constraints of the concrete geometry and the rendering of the content within its constraints.

Neither CSS or XSL-FO has a concept of abstract geometry, per se. Various common specific fracture situations need to be captured through specialized rules and properties. Given that these are common solutions to similar problems, it is by no means a bad thing that systems designed for humans with those problems take special note of them. Still, the concept of certain marks as responses to fractures can be a useful unifying principle for understanding concrete documents.

Extension of the operator/phylum grammar for the abstract syntax rules to allow for cross-classifications by more than one phylum, partial inheritance of structural components from phyla to operators, and the introduction of a special "unmarked" operator.

W3C XML Schema complex types and multiple substitution groups (in 1.1) capture many of the same instincts.

A taxonomy of concrete syntax functions.

Understanding CSS or XSLT stylesheet rules in terms of their functional role can serve to clarify how to organize them. In the context of developing a vocabulary and thinking about the rules for rendering it, considering marking functions can help in clarifying what the underlying vocabulary needs to distinguish, and what metadata may need to be added.

A taxonomy of concrete syntax mechanisms.

There sometimes seem to be an endless sea of possible presentation widgets in the world. A perusal of all the CSS or XSL-FO properties is mind-numbing. It can be helpful to see that in general a notation picks similar kinds of devices to convey parallel functions: if adjoinment is used to mark one case relation, it will be used to mark another. Thinking of a notation in such a holistic way, as a system of rules, can help in producing better and more consistent notations (or document renderings). It can also help guide rule inference. Knowing that larger scale components are marked with larger scale marks — more space, larger fonts, bolded text — one can infer something about the rules used to mark different levels of subdivision, and from this recover the structure of a document from its concrete form.

Use of case frames and marking theory as a inspiration for some aspects of the model.

Marking theory teaches us that marks indicating more specific or unusual entities will be more elaborate than marks indicating more common situations. It followed that mark cancellations apply in the same direction: marks for more specific functions cancel marks for more generic ones, in order that the mark we end up with is the more specific one. This principal finds an echo in the rules about template selection in XSLT and selector selection in CSS. Specificity wins. Case relations (parent/child) win over type relations (bare element names). Labels (ids) win over case relations. XSLT and CSS obviously have more elaborated sets of relations expressed in their selectors, however.

Applying the same perspective to document up-conversion allows us to make inferences about structural relationships. If a certain kind of mark (a bolded adjoinment with a colon separator, perhaps) indicates a case relation in one instance, it likely does in another as well. A very different kind of mark likely indicates that the component stands in a different logical relationship: part of a different parent group entirely.

Define the abstract syntax: what are the types? the case frames? the unique and referenced entities?

I have a price sheet. It has information about the store and a collection of items for sale. The store information includes a name, a description, various kinds of contact information (physical address, email address, phone number). Those items for sale come in groups, where each group has a label and a description. The items have a name, a description, and a price.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:this="http://mathling.com/price-sheet"
           targetNamespace="http://mathling.com/price-sheet"
           elementFormDefault="qualified">

<xs:element name="price-sheet" type="this:price-sheet"/>

<xs:complexType name="price-sheet">
  <xs:sequence>
    <xs:element name="store-info" type="this:store-info"/>
    <xs:element name="groups" type="this:item-group-list"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="store-info">
  <xs:sequence>
    <xs:element name="name" type="this:main-label"/>
    <xs:element name="description" type="this:para-list"/>
    <xs:element name="contact-info" type="this:contact-info"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="item-group-list">
  <xs:sequence>
    <xs:element name="group" type="this:item-group" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="item-group">
  <xs:sequence>
    <xs:element name="title" type="this:section-label"/>
    <xs:element name="description" type="this:para-list"/>
    <xs:element name="items" type="this:item-list"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="item-list">
  <xs:sequence>
    <xs:element name="item" type="this:item" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="item">
  <xs:sequence>
    <xs:element name="name" type="this:short-label"/>
    <xs:element name="description" type="this:para-list"/>
    <xs:element name="price" type="this:price"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="contact-info">
  <xs:sequence>
    <xs:element name="address" type="xs:string"/>
    <xs:element name="email" type="xs:string"/>
    <xs:element name="phone" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="para-list">  
  <xs:sequence>
    <xs:element name="para" type="this:para" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:simpleType name="short-label">
  <xs:restriction base="xs:string"/>
</xs:simpleType>

<xs:simpleType name="main-label">
  <xs:restriction base="this:short-label"/>
</xs:simpleType>

<xs:simpleType name="section-label">
  <xs:restriction base="this:short-label"/>
</xs:simpleType>

<xs:simpleType name="para">
  <xs:restriction base="xs:string"/>
</xs:simpleType>

<xs:simpleType name="price">
  <xs:restriction base="xs:decimal"/>
</xs:simpleType>

</xs:schema>
          

Here I have followed a convention of using named types and local elements, with lists x elements defined by a x-list type. Complex types are defined using xs:sequence but this ordering matters not to my notation, but to an XML parser processing an XML document that satisfies this schema. In fact, since ordering does not matter at the abstract syntax level, fixing the order at that level is fine.

<price-sheet xmlns="http://mathling.com/price-sheet">
<store-info>
  <name>Mary's House of Excellent Jam and Jellies</name>
  <description><para>We have been making artisanal jams and jellies from all-natural organic ingredients since 1998.</para></description>
  <contact-info>
    <address>111 Any Road, Some Town, USA</address>
    <email>nonesuch@example.com</email>
    <phone>408-555-1212</phone>
  </contact-info>
</store-info>
<groups>
  <group>
    <title>Jams</title>
    <description>
      <para>Jams are filled with delicious organic fruit.</para>
      <para>They retain more of fruit pulp than jellies.</para>
    </description>
    <items>
      <item>
        <name>Golden Summer</name>
        <description><para>Yellow plums, habañero, meyer lemons. Excellent with brie.</para></description>
        <price>5.25</price>
      </item>
      <item>
        <name>Christmas Jam</name>
        <description><para>Cranberries, oranges, ginger, and cinnamon. Have it with your turkey!</para></description>
        <price>6.00</price>
      </item>
    </items>
  </group>
  <group>
    <title>Jellies</title>
    <description><para>Jellies are strained and no longer contain fruit pulp.</para></description>
    <items>
      <item>
        <name>Hot Quince</name>
        <description><para>Quince and ghost pepper. Sweet heat!</para></description>
        <price>6.25</price>
      </item>
      <item>
        <name>Purple Bliss</name>
        <description><para>Pomegranate and blackberry. Pure decadence!</para></description>
        <price>10.25</price>
      </item>
    </items>
  </group>
  <group>
    <title>Chutneys</title>
    <description><para>Chutneys balance sweet, spice, and savoury.</para></description>
    <items>
      <item>
        <name>Classic Indian Chutney</name>
        <description><para>An exciting blend of fruits and spices. Water chestnuts add crunch. You'll eat it with a spoon!</para></description>
        <price>5.25</price>
      </item>
    </items>
  </group>
</groups>
</price-sheet>
          

Define the abstract geometry: what are the spaces? how do they compose? what are their properties?

I have a sheet, which may have multiple pages, each of which has a header space, a body space, and a footer space. The body space has columns, which consist of lines. Expressing this in the context XML/HTML stack is a little tricky, because neither XSL FO nor HTML/CSS make a distinction between abstract and concrete geometry and various common document devices (headers, footers, columns, lines) are treated specially and asymmetrically. We could sketch this out as an HTML template:

<html>
<body>
  <div class="header">
  </div>
  <div class="body">
    <div class="column">
    </div>
  </div>
  <div class="footer">
  </div>
</body>
</html>
          

With some basic CSS:

/* No "page" object to specify: use @page */
@page {
  height: 11in;
  width: 8.5in;
}

.header {
  line-height: 15pt;
  height: 2in
}

.footer {
  line-height: 15pt;
  height: 1in
}

/* No "column" object to specify: use column properties */
/* Note: to get this working in real browsers need more here */
.body {
  column-count: 2;
  column-gap: 1in
}

/* No "line" object to specify: put properties as document default */
html {
  line-height: 15pt
}
          

Or as a skeleton XSL FO:

<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <fo:layout-master-set>
    <fo:simple-page-master master-name="sheet" 
        page-height="11in" page-width="8.5in">
      <fo:region-body column-count="2"/>
      <fo:region-before extent="2in"/>
      <fo:region-after extent="1in"/>
    </fo:simple-page-master>
  </fo:layout-master-set>

  <fo:page-sequence master-reference="sheet">
    <fo:static-content flow-name="xsl-region-before">
      <fo:block line-height="15pt"/>
    </fo:static-content>

    <fo:static-content flow-name="xsl-region-after">
      <fo:block line-height="15pt"/>
    </fo:static-content>

    <fo:flow flow-name="xsl-region-body">
      <fo:block line-height="15pt"/>
    </fo:flow>
  </fo:page-sequence>
</fo:root>
          

We could capture the full abstract geometry model for design purposes in another XML Schema with extensions. It could then be used to generate HTML or XSL FO with the full concrete syntax:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:this="http://mathling.com/sheet/geometry"
           xmlns:ag="http://mathling.com/abstrct-geometry"
           targetNamespace="http://mathling.com/sheet/geometry"
           elementFormDefault="qualified">

<xs:element name="sheet" type="this:sheet"/>

<xs:complexType name="sheet">
  <xs:annotation>
    <xs:appinfo>
      <ag:orientation>depthwards</ag:orientation>
      <ag:direction>forwards</ag:direction>
      <ag:extent thickness="1layer+INF"/>
    </xs:appinfo>
  </xs:annotation>
  <xs:sequence>
    <xs:element name="page" type="this:page" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="page">
  <xs:annotation>
    <xs:appinfo>
      <ag:orientation>vertical</ag:orientation>
      <ag:direction>forwards</ag:direction>
      <ag:extent width="8.5in" height="11in" thickness="1layer"/>
    </xs:appinfo>
  </xs:annotation>
  <xs:sequence>
    <xs:element name="header" type="this:header"/>
    <xs:element name="body" type="this:body"/>
    <xs:element name="footer" type="this:footer"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="body">
  <xs:annotation>
    <xs:appinfo>
      <ag:orientation>horizontal</ag:orientation>
      <ag:direction>forwards</ag:direction>
    </xs:appinfo>
  </xs:annotation>
  <xs:sequence>
    <xs:element name="column" type="this:column" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="column">
  <xs:annotation>
    <xs:appinfo>
      <ag:orientation>vertical</ag:orientation>
      <ag:orientation>reverse</ag:orientation>
    </xs:appinfo>
  </xs:annotation>
  <xs:sequence>
    <xs:element name="line" type="this:line" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:simpleType name="header">
  <xs:annotation>
    <xs:appinfo>
      <ag:orientation>horizonal</ag:orientation>
      <ag:direction>forwards</ag:direction>
      <ag:extent height="2in"/>
    </xs:appinfo>
  </xs:annotation>
  <xs:restriction base="xs:string"/>
</xs:simpleType>

<xs:simpleType name="footer">
  <xs:annotation>
    <xs:appinfo>
      <ag:orientation>horizonal</ag:orientation>
      <ag:direction>forwards</ag:direction>
      <ag:extent height="1in"/>
    </xs:appinfo>
  </xs:annotation>
  <xs:restriction base="xs:string"/>
</xs:simpleType>

<xs:simpleType name="line">
  <xs:annotation>
    <xs:appinfo>
      <ag:orientation>horizonal</ag:orientation>
      <ag:direction>forwards</ag:direction>
      <ag:extent height="15pt"/>
    </xs:appinfo>
  </xs:annotation>
  <xs:restriction base="xs:string"/>
</xs:simpleType>

</xs:schema>
          

Define the concrete syntax: how do we choose to mark the types? the case relations? the unique and referenced entities? how do we choose to bind the abstract components to space? how shall we handle breaks?

Start with the type marks. Think of this as "which entities to I wish to mark in a way that makes them distinct from other kinds of entities?" Let us say we want to indicate the store info with surrounding box, and descriptions with italics, prices with a dollar sign.

Case marks are next. In technical notations or data tables literals are common. In human prose ordering comes into play. Here we decide that the email, and phone components of the contact info should be indicated with some text marks, and we will fix the ordering of the heterogeneous children of all components.

Are their labels or cross-references? How should they be marked? The short labels (variously with the case 'name' or 'title') will function as labels and be marked with bold, centered text, in decreasing sizes depending on the scope of the label.

Finally, let us consider grouping and separators. Certainly we will use whitespace to separate items in lists (group from group, paragraph from paragraph, etc.) with larger scale units separated by larger amounts of space. We also decide to separate the groups with horizontal rules. For grouping we determine which components are bound to which boxes: the store info to the header, the groups to the body. Finally, the fracturing rules are conventional: filling up a line overflows creates a new line, filling up a column creates a new column, filling up a page creates a new page and replicates the header.

Concrete syntax rules can be representing with a combination of XSLT and CSS. The XSLT maps the XML to something CSS can target and applies ordering rules.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:ps="http://mathling.com/price-sheet"
                exclude-result-prefixes="xsl ps"
                version="2.0">

  <xsl:output method="html" indent="yes"/>

  <xsl:import-schema namespace="http://mathling.com/price-sheet" schema-location="jelly.xsd"/>

  <!-- Affective -->

  <xsl:template match="/">
    <html>
      <head>
        <link rel="stylesheet" type="text/css" href="jellyh.css"/>
      </head>
      <body>
        <xsl:apply-templates select="." mode="grouping"/>
      </body>
    </html>
  </xsl:template>

  <!-- Labels -->

  <xsl:template match="element(*,ps:short-label)" mode="labels"> 
    <span id="{generate-id()}"><xsl:apply-templates select="@*|node()" mode="grouping"/></span>
  </xsl:template>

  <xsl:template match="*" mode="labels"> 
   <xsl:apply-templates select="@*|node()" mode="grouping"/>
  </xsl:template>

  <!-- Types -->

  <xsl:template match="element(*,ps:price-sheet)" mode="type">
    <div class="price-sheet"><xsl:apply-templates select="." mode="jointcase"/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:store-info)" mode="type">
    <div class="store-info"><xsl:apply-templates select="." mode="jointcase"/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:item-group)" mode="type">
    <div class="group"><xsl:apply-templates select="." mode="jointcase"/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:item)" mode="type">
    <div class="item"><xsl:apply-templates select="." mode="jointcase"/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:contact-info)" mode="type">
    <div class="contact-info"><xsl:apply-templates select="." mode="jointcase"/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:para)" mode="type">
    <p class="para"><xsl:apply-templates select="." mode="jointcase"/></p>
  </xsl:template>

  <xsl:template match="element(*,ps:short-label)" mode="type">
    <div class="label"><xsl:apply-templates select="." mode="jointcase"/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:main-label)" mode="type" priority="3">
    <div class="main-label"><xsl:next-match/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:section-label)" mode="type" priority="3">
    <div class="section-label"><xsl:next-match/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:price)" mode="type">
    <div class="price"><xsl:apply-templates select="." mode="jointcase"/></div>
  </xsl:template>

  <xsl:template match="*" mode="type"> 
   <xsl:apply-templates select="." mode="jointcase"/>
  </xsl:template>

  <!-- Case -->

  <xsl:template match="element(*,ps:price-sheet)" mode="jointcase">
    <xsl:apply-templates select="ps:store-info" mode="grouping"/>
    <xsl:apply-templates select="ps:groups" mode="grouping"/>
  </xsl:template>

  <xsl:template match="element(*,ps:store-info)" mode="jointcase">
    <xsl:apply-templates select="ps:name" mode="grouping"/>
    <xsl:apply-templates select="ps:description" mode="grouping"/>
    <xsl:apply-templates select="ps:contact-info" mode="grouping"/>
  </xsl:template>

  <xsl:template match="element(*,ps:contact-info)" mode="jointcase">
    <xsl:apply-templates select="ps:address" mode="grouping"/>
    <xsl:apply-templates select="ps:email" mode="grouping"/>
    <xsl:apply-templates select="ps:phone" mode="grouping"/>
  </xsl:template>

  <xsl:template match="element(*,ps:item-group)" mode="jointcase">
    <xsl:apply-templates select="ps:title" mode="grouping"/>
    <xsl:apply-templates select="ps:description" mode="grouping"/>
    <xsl:apply-templates select="ps:items" mode="grouping"/>
  </xsl:template>

  <xsl:template match="element(*,ps:item)" mode="jointcase">
    <xsl:apply-templates select="ps:name" mode="grouping"/>
    <xsl:apply-templates select="ps:price" mode="grouping"/>
    <xsl:apply-templates select="ps:description" mode="grouping"/>
  </xsl:template>

  <xsl:template match="*" mode="jointcase">
    <xsl:apply-templates select="." mode="labels"/>
  </xsl:template>

  <xsl:template match="ps:address" mode="case">
    <span class="address"><xsl:apply-templates select="." mode="type"/></span>
  </xsl:template>

  <xsl:template match="ps:email" mode="case">
    <span class="email"><xsl:apply-templates select="." mode="type"/></span>
  </xsl:template>

  <xsl:template match="ps:phone" mode="case">
    <span class="phone"><xsl:apply-templates select="." mode="type"/></span>
  </xsl:template>

  <xsl:template match="ps:name" mode="case">
    <span class="name"><xsl:apply-templates select="." mode="type"/></span>
  </xsl:template>

  <xsl:template match="ps:price" mode="case">
    <span class="pricechild"><xsl:apply-templates select="." mode="type"/></span>
  </xsl:template>

  <xsl:template match="ps:description" mode="case">
    <span class="description"><xsl:apply-templates select="." mode="type"/></span>
  </xsl:template>

  <xsl:template match="*" mode="case">
    <xsl:apply-templates select="." mode="type"/>
  </xsl:template>

  <!-- Grouping -->


  <xsl:template match="element(*,ps:store-info)" mode="grouping">
    <div class="header"><xsl:apply-templates select="." mode="separators"/></div>
  </xsl:template>

  <xsl:template match="element(*,ps:item-group-list)" mode="grouping">
    <div class="body"><xsl:apply-templates select="." mode="separators"/></div>
  </xsl:template>

  <xsl:template match="*" mode="grouping">
    <xsl:apply-templates select="." mode="separators"/>
  </xsl:template>

  <!-- Separators -->

  <xsl:template match="element(*,ps:item-group-list)" mode="separators">
    <div class="grouplist"><xsl:apply-templates select="." mode="case"/></div>
  </xsl:template>

  <xsl:template match="*" mode="separators">
    <xsl:apply-templates select="." mode="case"/>
  </xsl:template>
</xsl:stylesheet>
          

The general strategy here is to use modes to properly order the different kinds of marks from the least to most specific: affective marks before coherency marks before structural marks before identifying marks. We order case marks before type marks to ensure that the children of a grouping element have class names with the case labels. Joint case marks (ordering, principally) are separated from other case marks. We also need to use <xsl:next-match/> to march up the type hierarchy and make sure we get type and subtype marks. Priority is necessary to ensure we match subtypes first. For type marks we use match patterns that target those types.

Once we have the XSLT generating HTML with proper class attributes, the CSS applies the other marking mechanisms.

/* Affective */
.price-sheet              { font-family: "Comic Sans"; 
                            font-size: 12pt;
                            text-align: left }

/* Labels */

.label                    { font-weight: bold }
.main-label               { font-size: 20pt }
.section-label            { font-size: 16pt }

/* Types */

.store-info               { outline: 1px solid black }
.group                    { }
.item                     { }
.contact-info             { text-align: center }
.description              { font-style: italic }
.price:before             { content: "$" }

/* 
 * Here we see how CSS uses selectors both to target items in the abstract
 * syntax and (:before) as part of the definition of the concrete syntax
 * widget.
 */

/* Case */

.email:before             { content: "Email: " }
.phone:before             { content: "Tel.: " }

/* Separators */

.group + .group           { padding-bottom: 0.5in }
.item + .item             { padding-top: 0.25in }
.para + .para             { padding-top: 3px }

.store-info > .name       { display: block }
.store-info > .description  { display: block }
.store-info > .contact-info { display: block }
.group > *                { padding-right: 0.25in; display: block }
.grouplist > *            { border-bottom: 1px solid black }
.item > .name             {}
.item > .description      { display: block }
.item > .pricechild       { padding-left: 0.25in }
.contact-info > .address  { display: block }
.contact-info > .email    { display: block }
.contact-info > .phone    { display: block }

/* Grouping */

.store-info               { display: block }
.group                    { display: block }
.item                     { display: block }

/* Mechanics */

div                       { display: inline }
          

Define the concrete geometry: how big is the paper? how much space do we allocate for each part?

In an HTML plus CSS world, this comes down to @media rules for printed output, perhaps with exact positioning. This is the level XSL FO plays at, for the most part. It is also where this model gets tricky to apply directly, because the explicit separation of abstract and concrete geometry is not how rendering is conceptualized and the conventionalized rules (e.g. flowing from line to line and page to page) are not something we have direct control over, so there is nothing to add.

Iterate with actual or sample content until satisfied