Seminal Granularity: I <3 the </>

It's no secret, I love me some XML, whether as an exchange format like XBRL, a messaging standard like HL7 or NIEM, or a document framework like DITA or DocBook. I am not sure what appeals to me so much about data-enrichment using tags, but it has something to do with reducing entropy by adding structure and meaning. In addition, I would rather model something using the sort of extension and restriction available in NIEM than the classical inheritance strategies presented by OOP. I have heard from several sources recently that the seachange from an object-oriented to declarative paradigm is underway, and I am pleased.

But more than this, I just love the angle brackets in a way I could never feel about dot-notation, and I am not alone in this.

I am attempting to develop a notion I am calling "Seminal Granularity." This notion appeals to my background in structuralist literary theory - "seminal" and "granular" are both agricultural references, both seeds, but whereas "seminal" has patriarchal overtones, granular is more mercurial. Between the two axes there lies a tension, bringing to mind a transclusive dilemma.

Simply stated, the transclusive dilemma is this: when faced with modifying an object, do you create a reference to the object for modification, a seminal approach which binds the new object to the original; or do you create a clone of the object, a granular approach which results in modification to the new object becoming estranged from the original, releasing the object through mimesis.

A viral licensed open-source project, for instance, is by design both seminal and granular. The project itself exists as a single seed, and it allows granular modification with the caveat that modifications are returned to the original seed.

Edit: there is also an odd kind of tie in with this short story, The Ice Box.

The transclusive dilemma is a real phenomenon; you cannot do both. Seminal granularity should be about finding ways to negotiate this problem. A wave can't be a particle either, right?

Talking Points: Collaboration and Documentation

A few years ago I wrote about a project I developed for my then employers, which I open sourced under the name CaseBook. The intent was to single-source end-user documentation which could be be transformed into internal and client acceptance test scripts. As I developed it, the project involved XML, Schematron, XSL and XQuery, hosted in an eXist database and accessed using webDAV.

At the time, I had barely heard of DITA, the Darwin Information Typing Architecture, but the approach I took shared some ideas with what I later came to learn about DITA, using concept maps, separation of topics into tasks and steps and so forth. In the mean time, DITA has gained a lot of traction, and my SourceForge page has been hit maybe 500 times.

I have been giving a lot of thought lately to collaborative writing. As Anne Gentle has pointed out on her JustWriteClick 'blog, DITA shines in environments which have a strong collaborative or Agile approach, since both of these emphasize timely repurposing and multipurposing. One of the problems I was addressing with CaseBook was collaboration between development, documentation and testing resources. Now, in part, this was because I was working in a small team, and had responsibilities in each of these areas.

I still think there is a lot of value in facilitating collaboration between these groups, and were I to develop this project today, I would start with the DITA Open Toolkit from day one.

In addition, for the last four months, I've been working with Flex, mxml and ActionScript. One thing that intrigues me about mxml is that it is XML. For instance, what if you could generate end user, acceptance or client walkthrough documentation automatically from the mxml source? Transforming mxml to DITA seems like a useful technique.

Any thoughts?