Kristof's demo brought me back to converging two earlier explorations I had done with simple forms of DITA authoring.
The first idea was of using dictation-like directives to represent a speech-to-markup path for creating DITA content. Some directives represent processor setup and interactions, but others represented purely named styles for structured components. Some "schema awareness" allowed the components to be reassembled into a valid DITA task structure in the same way that you might convert styled Word components back into DITA (all the Word bolt-on interfaces use some form of this concept). For background, see http://learningbywrote.com/blog/2011/04/creating-dita-topics-using-twitter/ and http://learningbywrote.com/blog/2011/04/dictation-for-structured-writing/ .
The second was when Kristof's demo prompted me to go back and look at a previous wireframe editor demo I had worked up. The ahah moment was when I realized that the editable pieces I was separating from the source document in order to place them into the editing context were, in fact, completely analogous to the named style chunks in the dictation example. The image in this tweet represents that fusion (and the imaged content is related, of course):
https://twitter.com/donrday/status/583277630142578688
So what this suggests to me is that the essential, "contentEditable-mappable" parts of the Lightweight DITA specification could be reduced to a single definition of "core named components" with separate sets of mappings of each named component into its rendition in various formats: DITA, HTML5, Markdown, Drupal nodes, you name it. An associated schema represents how a sequence of components must be parsed to restore each rendition that conforms to the Lightweight DITA principles: DITA, HML5 in article/section wrappers, Markdown in well-formed hierarchy, etc..
I consider DITA a rendition rather than a source because now we can construct either Lightweight DITA or "light-expectation regular DITA" from a stream of components using the schema to direct the appropriate structure. This actually isolates the eventual design of Lightweight DITA from the components that represent the common space shared with all the Web tools we've been exploring (hopefully including Drupal as well). The components more or less are the actual "record copy" of the managed data while all the outputs built according to the schema are simply views on what we now consider to be the significant DITA data model. Don't worry--schemas are still needed and will continue to be the basis for specialization, but this effectively manages the content separately from the syntax of its storage format options (which is always reproducible by transforms).
Anyway, that is my wild hair rollup for this morning. I offer it for amusement or serious consideration--I'll probably continue to press it out because it has relevance to structured Web authoring whether or not the architecture makes any sense for LightWeight DITA (but I hope it does at least inform on possible separation of concerns in our mappings).
And this is not a joke on this first of April... just bad timing on my part.
--
Don R. Day
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday Twitter: @donrday
About.me: Don R. Day Skype: don.r.day
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday Twitter: @donrday
About.me: Don R. Day Skype: don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
Where is the knowledge we have lost in information?"
--T.S. Eliot
|
|
This email has been checked for viruses by Avast antivirus software.
|