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.

State of the MetaCommunity McCLIM fork - Apps "OK," fonts "Up in the air"

In my own small efforts in software programming, this year, I've made a fork of McCLIM -- a short overview provided in a previous 'blog entry, here at my DSP42 web log. It's been to nothing too sensational, as yet. I've made simply a few maintenance updates, and have added a dependency onto the mci-cltl-utils software system -- that much, as for applying a DEFCONSTANT* macro within McCLIM. 

Certainly, there are still some more maintenance updates to develop onto the fork, before getting along to any new developments onto McCLIM. In that regards, the last issue that I'd observed of it was that the font selector example is failing. It would appear to be due to something in regards to the interface onto the fonts table in CLX. Perhaps, that may easily resolved, insofar as the the present state of the source tree.  I think it serves to call some broader concerns to mind, however, insofar as developing an application architecture for Common Lisp desktop application development, within a contemporary computing environment.

Broadly, I've been using the Sharplispers CLX fork of Texas Instruments' original CLX codebase, and the CLX backend for McCLIM. I've tested a number of the applications provided in McCLIM, using the CLX backend. Specifically: The McCLIM listener, inspector, and debugger can be verified as running successfully, with that edition of CLX and on SBCL 1.2.5.76-65a44db. Furthermore, the Scigraph application has been updated to run by-in-large successfully, on that same platform, although again there are some maintenance issues with it.

I've also tested Climacs, on that platform. It runs successfully, too.

I'd tried applying the GTK Cairo backend for McCLIM, but without a lot of success in that port, presently. With some regrets, that may serve to make it more difficult to apply McCLIM onto mobile platforms. I had hoped that the GTK Cairo backend might've made a good component to apply for McCLIM on an Android platform, and well it still may. Presently, if it does not successfully run on so much as a contemporary Ubuntu Linux platform, then there's not much to show for it, at present.

One superficially minor change now developed in McCLIM: In regards to CLIM's multiple-value-setf behaviors, it should now be  portable onto ECL and CCL (ARM architecture), as well as SBCL (amd64) insofar as free/open source Common Lisp implementations. 

With regards to fonts: When adding a set of ASDF system definitions to the fork that I've made of the original Garnet source tree, I'd observed that Garnet is now extended with Truetype font support, such that utilizes CL-Vectors and extensionally, ZPB-TTF for providing a support for TrueType fonts onto CLX . The clx-truetype system may be applied not exclusively onto Garnet, though it is integrated with Garnet as in the gem-font-methods file in the same source tree.  One might hope that it would be fairly trivial, to apply clx-truetype likewise onto the CLX port in McCLIM. Insofar as with regards to fonts and typesetting in CLIM itself, there -- I think -- is one of the broader concerns of the matter. To a few superficially simple questions:

• How may it be possible to provide functions for denoting superscript or subscript typesetting, in CLIM?
• If not, then how may such functions be defined effectively onto McCLIM?
• To what practical ends may such developments be focused?
• May it be possible to implement the entire Cascading Stylesheets visual formatting model onto CLIM? Specifically, of CSS 2.2?
• Note: `vertical-align` and related properties in the CSS model for inline blocks
• Extensionally: How may it be possible to implement an entire MathML interface onto McCLIM?

Such questions might seem trivial, at the outset.

If the CSS 2.2 visual formatting model may be implemented onto McCLIM, perhaps it may be implemented as to extend of MetaObject Protocol. Hypothetically, any one or more metaclasses may be defined as to allow for a modular  implementation of the CSS 2.2 visual formatting model, such that the implementation may also be portable onto XSL Formatting Objects (spec version 1.1). Sure, it would be nothing too conceptually original, to develop an application protocol that may extend of both and that may be integrated with McCLIM, furthermore -- even insofar as for representation of text according to textual formatting specifiers. Historically, there's also DSSSL

XSL-FO and DSSSL may be particularly suited to a page-oriented media, if not specifically a page-oriented model for graphical user interface design. Insofar as page-oriented media in CLIM, of course there's also the McCLIM PostScript backend

Orthogonally, an implementation of SVG onto McCLIM may seem pragmatically "Out of the question," at this time. Though it would serve to keep pace with contemporary widget toolkits defined in C and C++ -- such as Qt, GTK, and Cairo, all of which provide support for rendering of graphics developed in a medium of SVG -- however, it may represent another distinctly non-trivial design issue to approach in any single fork onto McCLIM.

Of course, the design proposed of the Dobelle-App system -- as specifically with regards to development of mobile  applications in Common Lisp -- it would require that McCLIM or any other single graphical user interface toolkit would be suitably applicable in Common Lisp on a mobile platform, as well as on a desktop platform -- furthermore, beyond simple "Proof of concept" implementation. If a framework may be developed and applied for CLIM applications on desktop and mobile platforms -- not only for backing of a thesis article, but furthermore as a framework for commercial application development -- it would well need to be provably applicable in a commercial domain, in every feature of such a framework.

Still, such a matter may seem trivial, at the outset -- and well, there are so many novel things to take to attention, otherwise?