Elsewhere I have suggested that Kari Kraus's musings on accidentals and substantives led me to contemplate using an ID/IDREF mechanism to assist an XSLT transformtion in selecting which of two different characters would appear at a specific spot. The Text Encoding Initiative Guidelines provide the author with the possibility of using the value of the "exclude" attribute on the <c> element (the attribute is also available for other elements). A fine mechanism for exclusive alteration. Great for providing a use case for the teaching a module of XSLT relating to the application of the xsl:if element using a test on an attribute value.

When I encountered another use case, it became interesting to consider inclusive alternation as again, the appearance (or not) of the content of an element in a specific spot. I was rather pleased to be able to consider inclusive alternation in relation to position. Again the ID/IDREF mechanism assists in expressing a relation in XML markup that can then be transformed in XSLT. <title> <w next="MetaM" id="HyperM">HyperMnemonics</w> ... <w prev="HyperM" id="MetaM">MetaMimetics</w> </title> Handy for introducing the xsl:choose element with xsl:when testing on the value of "prev" and "next" attributes and supplying an xsl:otherwise option. A yen for reversals and XPATH can make an appearance in the lesson play with the use of following::sibling and preceding::sibling to accomplish some matches.

The Text Encoding Initiative Guidelines also provide for the markup of morphemes for the hypermimetic. And for the metamnemonic there is some XSLT that concatenates the content of a <num> element of type "accession" with the content of a <label> element of type "category" to create an HTML anchor element in the output (i.e. <a name="#label_num"></a>).

The memory part is about getting the correct label attached to the correct spot. Imitation, like acting, is about threading labels and spots into dismantle-able chains.

Certain rendering engines in certain versions of certain browsers do not implement the @import mechanism available in Cascading Style Sheets (CSS). Given these conditions, stylists have some choices: Option One Maintain one set of modular stylesheets for all browsers whatever the implementation; rely on graceful degradation. Option Two Offer two sets of stylesheets: a single basic all-purpose stylesheet and a more elaborate set of stylesheets (built out of @import declarations); use Javascript to detect browser version and determine the appropriate stylesheet to serve. Option Three Give up styling, let user preferences determine display. Option Four Give up styling but implement an interface where a user could generate a stylesheet of their own devising.

At present, I am tending, for the Jardin project which is exploring content modeling of blogs via the Text Encoding Initiative Guidelines, to opt for Option One. The modularity that I have introduced into the CSS files relates to the background colours of the body and the divs of class entry. Depending upon which CSS file gets imported, the colours are reversed.

Option Two appears in and of itself to be lots of work for little return. However, the notion of browser version and setting detection driving a selection of a stylesheet can be coupled with a command to write content. A distinctive combination of message and style can alert or remind users of the control they can exert over display. Why bother? Why not just serve up a document with the message "best viewed with browser [name]"? Because that little message assumes that the user has not overriden the browser settings and that the content pusher can always control the styling. It also assumes that the stylist has chosen colours that work across all platforms, has ensured that the colours for text, background, links, visited links are all set (and none left to user discretion), has ascertained that font families and sizes are appropriate to a variety of screen resolutions and user perceptual abilities and preferences. "Best viewed" is a very relative designation and browser choice alone does not determine its measure. So why not lean towards a single stylesheet for all or no stylesheet at all? There is some value in thinking through what could be accomplished by browser-version dependent stylesheets. Option Two becomes interesting when an HTTP refresh response can situate it as an introductory step to Option Four.

Option Four seems to be a route that demands HTML forms, cookies and other fancy stuff. End state: automation, user stupidity. Just thinking through a possible implementation from the perspective of the what the user needs to know uncovers some very interesting assumptions. An interesting question arises as to where to store the generated stylesheet (server or client side?). A collection of generated stylesheets could become accessible to others through a library housed on a server. For me, this space of the collection as differentiated from the space of the generation also lays bare some other assumptions.

While authoring a stylesheet there is the desire to move between the declarations in the stylesheet file and a rendering in some display. One wants to see if one is getting what one wants. HTTP is stateless protocol. Copies of the stylesheet and document are fetched and cached. If users know about file systems, they can transfer files from cache (which gets flushed periodically) to less transient storage. If users know about how to either override stylesheet settings with their own stylesheet or can modify files and create their own stylesheet associations, then Option Four can be implemented without any fancy stuff. The objective of facilitating user generation of stylesheets can be accomplished via text files: a simple listing of the elements available, an example of a stylesheet that can be modified, and possibly a pointer to a resource for more information on CSS or file systems or etc. This is in the great tradition of the read.me file. No magic without application.

Option Three is the de facto case with browsers that do not implement CSS. From a rendering perspective, the glory of divs in HTML 4.0 is in the line breaks they cause. Always useful to check one's HTML output with a text-only browser. Makes for scrolling heaven.

Kari Kraus under a rubric which highlights the term pixel driving launched me on a meditation that gave me the notion of exploring the mimetic and mnemonic through hyperspace and metadiscourse. Kari's blog is called accidentals and substantives. A search string with Kari's name plus the term "pixel driving" will turn up a path to the November 2003 entry in question.

In the spirit of paying attention to detail, Kari's pixel and accidental musings inspired me to develop a content model that allows play with a single character. A hyphen taken as a minus sign leads one to contemplate the possibility of a plus.

For the technically-inclined: here is the XML conforming to the Text Encoding Initiative Guidelines: <c id="dash" exclude="plus">-</c> <c exclude="dash" id="plus">+</c>

The XSLT files that handles the output to HTML use a modular approach. A top-level xsl:include element is used to select the template generating the output of one or the other character in a given version. Both templates could be called in a given XSLT file to generate, for example, a header and footer which differ only by a dash or a plus, or a header with both versions one above the other (a plus followed by a dash or a dash followed by a plus) or a square formed by some combo (+, -) and (-,+). A giddy multiplication of of Cartesian take on a Johari Window.

Suffice it for now to mention that the exclude attribute in TEI takes a value that is of type IDREF. A value of type IDREF references a value of type ID. Values of attributes of type ID are unique in a given document instance.

Now I find myself asking how it is that humans create unique identifiers on the fly to help with memory work. The third house on the block before the fire last May... I find myself asking what sequencing might have to do before, after and across in reading and authoring blogs. The URL to Kari's blog is http://karik.wordherders.net/.

Elsewhere, I have remarked that blog authors can and do play with the serial potential of titles to entries and how searching and ordering provide alternative reading paths. Part of this observation comes from attempting to model the content of a blog in XML following the Guidelines of the Text Encoding Initiative. The other part came from authoring in TEI. Both trajectories involve encounters with structure.

I chose to model blog entries using the <div> element. The <title> element appears as a child of the <head> element which is itself a child of the <div> element.

Other content models are possible. Common content models mean predictable structure and if structures are predicatble and common, then processing modules such as XSLT and CSS files can be swapped.

If several blogs and authors use the same content model, it becomes possible to research patterns over time. Imagine: author So-and-so favoured titles consisting of adverbs beginning with such-and-such a letter for a run of such-and-such a number of entries and when the author broke the pattern a ripple was felt in a particular cluster of blogs. A dream of formalist feedback!

I wonder about how blog authors begin to write entries. There are choices in opening the composition process: they might begin with a title or append the title afterwards. Before the products of composition are published, the writers could shuttle between title and entry and make many many changes.

I am interested in this in terms of the locus of compositional attention. A clue to remembering what happens in composition is to recall the reader. In some displays, the reader is afforded with a list of recent entries. Such lists usually pick up the titles to the entries in reverse chronological order. An author could play with the serial nature of such a listing. To embed a palindrome. To sketch a run through a spectrum of colours, seasons, planets. To establish a formalist pattern (or disrupt an established pattern) by an arbitrary run through a given alphabetic or numeric series. Such compositional behaviour could be called title tracking.

In French the semantic fields of cutting a loaf of bread and broaching a subject intersect through the verb entamer. So easy to imagine loaf cutting as broaching. And titles as serrated knives.

I rolled the die before beginning to write. Given that I know how the transformations work to send the entry to one of six alternatives, there is some chance that the knowledge of destination would exert some influence upon the content of the writing. This is espcially true of the roll of the die indicates that the entry would land in all the HTML (1) output or none (6). Three voices could emerge based on the partitioning of the publication space.

I will roll the die after the entry is written. This may lead me to rework content. I could want to populate all the output possibilities with a piece of content and the workings of chance may not favour the result that I seek. A game of variations could ensue.

Interesting how voice is connected with a projection into space. Also interesting that the degree of volume or amplification is the result of the encounter between a resistence and a desire.

test entry para

There is an unfolding about.