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.