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`
Ed. Note: There's also something to write about `git gc`
No comments:
Post a Comment