Re: [FrameSGML] Re: Office 2003 Beta (long)

[DW Emory <danemory@xxxxxxxxxxxxxxxxxx>]

Some of your comments suggest that the writers who originate documents should
be separated from the "Document Designers" who define the formatting.
Such an approach goes back to the dark days before WYSIWYG DTPs,
and before the advent of template designs which predefine formatting, thereby
reducing the job of the writer simply to select and apply the applicable 
tags from the template.
Of course, in structured Frame documents, the writer no longer must even select
the correct format tags. Instead, (s)he simply selects the proper element 
from the
element catalog, and the EDD format rules do the rest..

An EDD and a companion template certainly provide the simplest way for a writer
to optimally format and lay out a structured document IAW a template.
If the writer attempts to override the template, all such overrides can be
quickly and automatically removed.

The problem is that, when a structured Frame document is exported to SGML or
XML, the EDD's format rules cannot be converted to a DSSL or XSL instance
which preserves the original formatting and layout. Thus, a third-party DSSL
or XSL developer, who does not fully understand the writer's original intent,
can easily produce unintended consequences which could botch up the readability
or understandability of the document. That is a serious problem which 
cannot be
treated lightly. There is a real danger that this kind of disconnect 
between writer
and XSL/DSSL developer will negatively impact the usability or safety of 
the product
being documented.

Although I fully realize that it should always be an option to format an 
XML document
instance differently from the way the originator intended, I also believe 
it to be essential that
an XSL instance always be provided which formats the document in exactly 
the way
the originator intended.

Right now, that's not possible using FrameMaker to originate structured 
documents.
But achieving that goal, not only for format but also for layout, is, I 
hope, what the
OpenOffice initiative by Oasis is all about.

The alternative is what Microsoft is offering in Word 11. But that approach,
for all intents and purposes, bypasses XML and replaces it with the proprietary
WordXM format.

At 10:38 AM 3/25/03 +0100, Chris wrote:
<snip>
>Whether you accept it or not, a fundamental premise of general markup is
>that this type of formatting does convey meaning, and that meaning is
>directly related to the structure of the document.  That is to say, with
>markup you can express what each of these formatting artifacts express
>in terms of document structure.  It's like saying there's a deep meaning
>or grammar to a document that can be expressed by any number of specific
>grammars.  The deep grammar is one of structure, and the specific
>grammars are the style conventions used to express that structure.

Disregarding the fact that you completely ignore the page layout issues which I
mentioned, something that the OpenOffice initiative addresses, your 
argument that
general markup is sufficient to define formatting falls of its own weight 
when you
examine the many "standard" DTDs out there, where, clearly, general markup
is often insufficient to properly and unambiguously specify formatting. 
There's no
question that FrameMaker has the best solution with its EDD approach, which 
includes both
structure rules and format rules. The problem, however, is that all the 
formatting information
is lost when a Frame document is exported to raw SGML or XML instances. 
Thus if such instances
are opened in software other than FrameMaker, a substitute for the EDD 
format rules must be used
to format the documents, and that approach is guaranteed to produce a mismatch
with how the document was intended to be formatted.

Take, for instance, the ubiquitous Para element in ATA specs, where it is 
used in literally hundreds of
different contexts. An EDD which I developed for an ATA spec, for example, had
approximately 100 pages devoted solely to format rules and format change 
lists for
the Para element. This Para element has no attributes. But in many contexts
the first Para element under a parent ListItem element (that's not it's 
real name) must be
autonumbered in a multi-level list. However, the parent ListItem element's 
structure
rules permits other elements (e.g., notes, cautions, warnings) to precede 
the Para
element that needs the autonumber, and those predecessor elements
also contain Para children. Thus, it is impossible for format rules to 
determine, based
on context alone, which Para element is the one which requires the
autonumbering specification (contained in a format change list). Thus, it 
became necessary
to add a Yes/No choice-type attribute to the Para element. Also, because of the
way the structure rules are specified, it was impossible to determine 
whether a particular
ListItem element (which also has no attributes) is the first one at a 
particular list level., in
which case the autonumbering must be re-started at 1, and lower-level list 
levels must to
be reset to 0 Thus, I had to add a FirstItem attribute to the ListItem element.

Another example in that same ATA EDD occurred in the single-level Unlist 
and Numlist list types,
which can be embedded under many different elements, including multi-level 
lists. In those cases,
the Para elements under each item in an Unlist or Numlist must be correctly 
indented under the parent.
Here again, it was impossible, based on element structure rules alone, to 
determine what the
indentation should be. So, I had to add an Indent attribute to the Unlist 
and Numlist elements
in order for the format rules to specify the correct indentation in all cases.

There were numerous other cases within that same EDD where it became 
necessary to
add attributes (e.g., a Break attributeto specify whether a Title element 
should start a
new page, and a KeepWith attribute to specify whether a Note, Caution or 
Warning
should be kept with the text that precedes or follows it).

Of course, all of those added attributes had to be dropped on export to 
SGML in order
to make the documents conform to the ATA DTD.

Even in EDDs which are not based on an existing DTD, attributes which specify
formatting information are highly desirable, because it gives the document 
designer
more power to achieve the desired formatting results.

FrameMaker/FrameMaker+SGML Document Design & Database Publishing
DW Emory <danemory@globalcrossing.net>


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **