Re: Single source docs for multiple media? (long)

[Mark Baker <mbaker -at- OMNIMARK -dot- COM>]

Geoff Hart wrote


>Mark Baker makes the excellent point that <<A WYSIWYG single source
>authoring environment is not the holy grail, it's a contradiction in
>terms.>>
>
>To which I say a hearty amen. Until the standard computer monitor is
>at least 8.5X11 inches in portrait mode (vertical) and has 300 dpi
>resolution or better, the paper and online media are too different
>for a "one size fits all" approach.

Resolution is one minor difference between the media. Improving online
resolution will be a good thing, but it will not make media equivalent. It
will not give paper any of the virtues of the online media.

>Within the abovementioned
>limits of screen resolution, the same Acrobat file will work equally
>well in print and on-screen. Yes, you're sacrificing the additional
>functionality of the online medium, but at least it's a decent
>compromise.

The question is, is this still a "decent compromise" from the users point of
view? Early movies were made by bolting the camera in front of a stage play
and filming it. Audiences were wowed at first, but this soon became an
unacceptable method as filmakers discovered the real capabilites of their
medium. PDF represents the same stage of development in online media. It is
unlikely to be widely acceptable for much longer. (Except as a way of
distributing information intended to be printed, for which it seems to be
ideal.)

>Mark then continued: <<The best you can hope for with WYSIWYG is to
>do an after the fact down-translation to another media format. It is
>a down translation because, unless the author intervenes, which would
>disqualify the process from being called single source, the target
>output can only contain a subset of the structure and formatting
>available in the original.>>
>
>That leads me to a question. It would seem to me that SGML was
>intended primarily to solve just this problem. If you define your
>content rigorously, then all you should need is an appropriate output
>filter for each medium to produce the desired product. The obvious
>problem with this simplistic statement is that you can't automate
>good design, but I strongly suspect that products whose output
>formats are equally structured for the online and print versions
>(e.g., fill-in-the-blank forms, database output such as "baseball
>cards", etc.) would be quite amenable to single-sourcing.
>You'd still need occasional tweaking of the product, but you should
>be quite close in many cases. Comments?

This was not the problem SGML was supposed to solve, and SGML is at best
part of what is needed to solve it. SGML and XML both let you define tagging
languages that you can use to give you data an explicit structure. Data with
an explicit structure can then be processed to produce different forms of
expression. However, the linear structures supported by SGML/XML are not
sufficient to capture all the structure required for robust single sourcing.
You need non-linear structures, such as those provided by a relational
database.

>For example: <<We produce HTML, PDF, PostScript, and WinHelp from a
>... media neutral information set maintained in a database. The
>outputs are all designed to take full advantage of the structural and
>formatting possibilities of their target media.>>
>
>That seems to be exactly what I was getting at, if I'm understanding
>you right. Can you provide more details on the product and outputs?
>It would make for an enlightening case study if the methods or data
>aren't proprietary!

The method used is Component Based Information Development (CBID). I gave a
paper on CBID at SGML '95, so you can find it in the proceedings. The
general principles are also stated in the OmniMark white paper on content
management (http://www.omnimark.com/white/w_content.html).The basic ides is
that you do not develop documents, but media-neutral information components.
Information components are stored in a database with enough relationship
information to allow them to called up in any way that suits you. To create
an information product you synthesize an appropriate set of information
components and process the result to create the desired media format.

The tools we use are home grown. The make heavy use of the OmniMark
programming language, SGML/XML,  and standard relational database systems.
The system is not a commercial product, but we can create such systems for
customers.

If my proposal is accepted, I will be demoing our system at the next STC
conference.

>There's one very real advantage of WYSIWYG that you haven't
>mentioned, and it emerges under the guise of information design. I
>work continuously with graphic artists and desktop publishers to take
>"single-source text" and readapt it to various media (e.g., from a
>report to a slide presentation to a video). There are some undeniable
>synergies possible when you work "directly" in the final medium
>because you can interactively modify your approach to suit the new
>medium. Of course, then you're no longer single-sourcing in the sense
>of the original question.


This is the area of what I call presentation based semantics. That is, the
use of display characteristics to convey meaning as opposed to simply using
them for aesthetic or ergonomic purposes. It is not impossible to use
presentation based semantics in a single source system, but it has to be
carefully planned and executed. In most cases you will probably want to give
up, or scale back on, presentation-based semantics when single sourcing. If
doing so enables you to deliver information products that take full
advantage of each media, the gains will outweigh the losses.

---
Mark Baker
Manager, Corporate Communications
OmniMark Technologies Corporation
1400 Blair Place
Gloucester, Ontario
Canada, K1J 9B8
Phone: 613-745-4242
Fax: 613-745-5560
Email mbaker -at- omnimark -dot- com
Web: http://www.omnimark.com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=