Towards Developing a DITA Editing Platform on FreeBSD

Having developed a certain sense of interest with regards to writing technical documentation, I've been studying periodically about the Darwin Information Typing Architecture (DITA). There are a number of things that I would like to highlight about DITA, as in a sense of a thesis document – I've tried to collect my notes, as such, with Evernote. Thus far, I have been unable to write any single thesis document about the topic, rather developing only a series of itemized lists of notes, and a small bibliography.

Presently, I think it may be as well to begin writing some narrative text about DITA. Although I may not feel as able to write fluidly, in a digital media – as juxtaposed to a media of graphite and paper, with clipboard, to an older style of desktop writing appliance – but it is surely easier to share a work of writing produced in a legible digital font – here juxtaposed to my own cursive handwriting and ad hoc visual layout approaches, as when writing with pencil on paper.  Sure, I have begun to sketch out an idea for a more fluid style of sketching in a digital media, but it would need some work in regards to ergonomic presentation and editing of vector graphics, and therefore may depend on software not yet developed for the Common Lisp Interface Manager (CLIM). Presently, I am more preoccupied of developing a workflow towards DITA editing with free/open source software (FOSS) tools. Though I have looked at both of the XXE XML editor and OxygenXML for a DITA workflow, I would like to start writing DITA with a platform more familiar to me. Personally, I'm comfortable with Emacs and pSGML.

In regards to any manner of perhaps esoteric features of DITA – such as, DITA linking, DITA content replacement, and any broadly semantic qualities of DITA's  topic element classes – it might not seem that a baseline Emacs + pSGML environment could be completely sufficient, If applied primarily as a DITA editing enviromment. The Emacs + pSGML platform, of course, can be extended with Emacs Lisp. Although Emacs, in turn, may not seem like a very rigorous programming enviromment,  as when juxtaposed to the Eclipse IDE or IntelliJ IDEA platforms – both of which are developed, primarily, in the Java(R) programming language – but I think there is a manner of an incentive in the simple convenience of the interactive, functional command interface of Emacs + pSGML. It may seem to be enough that I might not be excessively distraught about the absence of programmatic rigour in the Emacs Lisp programming language, juxtaposed to Oracle's Java(R).

So, but in that I would not wish to develop an manner of an ivory tower of this concept, and I will be writing with Emacs on a FreeBSD desktop, I think it needs a a sense of a project, in itself. I propose that a FreeBSD port can be developed of each of: The DITA 1.2 Document Type Definition (DTD) files, there integrating with the XML entity resolver's configuration on FreeBSD; the DITA Open Toolit, likewise to be integrated with the host's XML entity resolver, moreover to be applied with the user's own ASF Ant configuration. If anything analogous to the Comprehensive PERL Archive Network (CPAN) may be developed, moreover, as to provide a software distribution service for extensions to the DITA DTDs and DITA Open Toolkit (DITA OT) XML stylesheets, perhaps such a thing may be anyhow designed onto CORBA services, moreover the CORBA Component Model (CCM), if not Java(R) and OSGi services. Of course, from an end user's perspective, that might be secondary to the availability of a FreeBSD port for each of those two existing components, respectively the DITA DTDs and DITA OT.

Fourthly, as towards a concept of applying DITA in an open documentation system, there is a simple concept of a topic repository model that may be developed, in a manner of writing DITA as like for a sort of an – albeit not primarily web-based, and insamuch not web-editable – Wiki-like format. Though it may seem to loose something of a popular incentive, for it not being a web-editable format, but inasmuch as that a DITA editing platform may serve to provide a manner of editing support not easily provided altogether with a web-based interface environment, then perhaps there may be an adequate "up side" to the design decision, as such.

Immediately, I am somewhat distracted of the tedium of making a complete Git clone of the WebKit source code repository – perhaps this is referred to as multi-tasking. It seems that the initial Git fetch must be run incrementally, onto that same source code repository. It's presently at `--depth=20000`, in no small detail. I have referenced only a couple of forum topics [Matthews 2010][midtiby2011], to try to resolve that a complete `git clone` onto that source code repository has consistently has failed. Proceeding to to a `git fetch` at `--depth=60000`, the Git incremental-clone procedure succeeds, so far.

Ed. Note: There's also something to write about `git gc`

Towards a Definition of a Document System in CORBA

In beginning to develop a concept for a mobile application utilizing the automotive OBD-II/CAN protocol and an OBD-II interface such as the ScanTool 426101 OBDLink MX, the author has begun developing a corresponding concept of an automotive notebook, such that would be accessible via a CORBA service. Though it may be a concept somewhat less stylish than a concept of a networked car with a Bluetooth or WLAN OBD-II/CAN interface, it is the author's opinion that the concept of an automotive notebook is more the appropriate concept to develop, as the first essentially challenging feature of the design of the application.

The author is familiar with some concepts ascertainable of structured markup formats, including the stylish old adage that XML was defined for separating logic of document structure from style of document presentation. Contrasted to a document format such as HTML or LaTeX, those defining -- essentially -- both structure and presentation information, at least that old stylish adage made for a few convenient keynotes for authors assisting in the original popularization of XML. XML itself -- similar to HTML -- is accompanied with a formal Document Object Model (DOM), and is accompanied furthermore by a formal XML to IDL binding definition -- namely the XML Valuetype mapping -- such that would allow for developing an application interface onto an XML like document structure, via CORBA.

In defining an automotive notebook data type in CORBA IDL as a data type subsumed by notebook, and the notebook data type subsumed by document, the software design then may be implemented as it being orthogonal to a design for a CORBA-based document service.  The Document IDL interface, of course, would not be all that there would be to such a thing, though -- in itself -- it presents some particular design concerns, as to its implementation.

Offhand, the author knows of at least a few variably "Mobile-friendly", variably "Editable" document formats, such that masy occur to mind as with regards to how a CORBA-based document service may be defined, viz a viz

• EPUB Book
• ODF Document Package
• DocBook Article

In the author's opinion, the last one of those three presents the most appealing alternative.

Albeit, DocBook does not -- in itself -- define a document container format, such as may be applied for purpose of streams-oriented document storage and streams-oriented document distribution -- namely, in as any single document being stored as a single filesystem object including text, graphics, tables, charts, and so on. In the author's opinion, the appeal of DocBook for this document system design, the appeal is not so much for developing a streams-friendly storage model, but rather for developing a semantically meaningful markup model, separate to any manner of an aesthetically appealing presentation model -- as whether for visual document presentation, or audible document presentation, or for a braille document presentation.

As with regards to developing a visual presentation model for applications in a document service as would implement the XML valuetype mapping for CORBA IDL, a concept of XSL formatting objects (XSL-FO) occurs to the author's consideration. XSL-FO is implemented in Apache FOP. In a sense, XSL-FO is to XML as like DSSSL is to SGML. In another sense: XSL-FO serves to develop a page-oriented rendering for XML, via XSL transformations.

With a further binding for Cascading Sytlesheets (CSS) defined onto the XSL-FO layer in the presentational aspects of the same document service -- thus, with an object model for data structures in a manner of CSS presentational information, then defined with a set of CORBA IDL interfaces -- the presentational aspects of the document service may then be designed with a complete data model, insofar as data structures for presentation of the underlying XML valuetype mapping. To implement a set of human computer interface (HCI) elements for the same document service design,  however, that would be one of the inevitable "Tricky parts."

If in the design of a software model, one may make reference to an item of existing work, in software applications -- even insofar as with regards to designs of human-computer interfaces -- the stylesheet editing components of UX Write then occur to the author's consideration. UX Write is an application available on Apple iOS mobile devices. In the HCI design of UX Write, as the author recalls, UX Write provides a separate interface for each of style editing and for document editing. The features defined to a style in the style editing interface, then, would serve to affect how the markup of a document in UX Write is presented in the document editing interface. The document editing interface may as much be viewed as a markup editing interface, but not in so far as for editing of bare markup -- rather, a sort of stylized markup editing interface. Thus, there is a design concept available, insofar as for how a document editor application may be implemented with a set of separate features for document editing and for presentational style editing. That, in itself, would still not serve to provide a convenient document editing toolkit, though it is towards a design of something like as so,  for an implementation onto CORBA, whether or not with round-trip serialization onto individual files in a filesystem.