RE: SGML, DTDs, EDDs, and FOSIs

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:22 AM 5/23/02 -0400, eric.dunn@ca.transport.bombardier.com wrote:
>if there was even so much as an Adept FOSI manual that explained the 
>coding of a FOSI, translating the FOSI manually line by line wouldn't be 
>all that difficult.

You mean so as to convert a FOSI into the format rules for an EDD?
The FM+SGML approach using format rules and format change lists within the 
EDD, thereby combining the DTD and the formatting information in a single 
document, is far more elegant and powerful than FOSIs, DSSLs, XSLTs, and 
XSL-FOs. That's why so many SGML and XML shops use FM+SGML as their print 
engine. But of course that doesn't solve the problem of formatting the 
information for display in am SGML/XML browser, so they're still stuck with 
FOSIs, DSSLs, XSLTs, and XSL-FOs for that purpose.

Which raises the question of why Adobe doesn't produce either of the 
following killer apps

1. Provide the capability to convert EDD format rules into a DSSL or an XSLT

2. Develop an on-line browser that uses an EDD instead of a DTD with a DSSL 
or an XSLT.

Perhaps Adobe refuses to look at these opportunities because they would 
compete with its flagship product, Acrobat.

I might add that the whole problem of formatting information that is 
conformant with a DTD is compounded by the prevalent attitude among SGML 
"purists" that any formatting information contained in an SGML or XML 
document instance is an unacceptable "contaminant." Thus, most industry and 
government DTDs are structured in a manner that virtually ignores how 
document instances of those DTDs can be properly formatted for display or 
printing. The entire set of ATA DTDs, as well as military DTDs such as 
38784 are prime examples of this deficiency.

For example, in ATA DTDs there is process list having up to 7 indented 
levels (Prclist 1-7), in which each list item at each of the 7 levels has 
the following content model:

Title?, ((Warning*, Caution*))?, ((Para | Tabdat | Table | Unlist | Numlist 
| Note)+), Graphic*

Simplifying this content model to eliminate tables and graphics, it becomes:

Title?, ((Warning*, Caution*))?, ((Para | Unlist | Numlist | Note)+)

Inclusions in any list item are:

Effect, Revst, Revend, Cocst, Cocend, Hotlink

So, these inclusions can appear anywhere within a PRCitem or any of its 
children.

Note that the Title element cannot stand alone, but a Para element can. 
Normally, the first Para element within Prcitem has the item number,  but, 
if a Title element precedes the first Para element, you may or may not want 
the Title element instead of the first Para element to have the item 
number. But given the content model above, with its inclusions, there is no 
definitive way to determine, using an EDD format rule (or a DSSL or FOSI) , 
whether a Para element is the first one within a Prcitem. Thus, it is 
necessary to add a formatting attribute named Firstpara  (values are 
Yes/No) to the Para element in order to eliminate this ambiguity.

Also there is no way to determine whether the item number should be applied 
to the Title element or the first Para element within each list item. There 
is also a third option, which is not to number the item at all. To resolve 
this issue, another formatting attribute named Numbering (values are Title, 
1stpara, and None) to the Prcitem element.

Notice also that a Numlist or Unlist can stand alone under a Prcitem, or it 
can be inserte below a numbered or unnumbered Para element within a 
Prcitem. The desired level of indenture of such sublists should be a 
subjective choice of the author, thus a formatting attribute named Indent 
(10 values) is required in the Numlist and Unlist elements to establish the 
desired level of indenture.

Notice also that multiple instances of alerts (Note, Caution, and Warning 
elements) can be stacked immediately below a Title element, immediately 
above the first Para element, or, in the case of Notes, anywhere within the 
list item. It is generally regarded as vital that these alerts be kept on 
the same page as the text to which they pertain. Also, the level of 
indenture of the alert text should correspond to the indenture of the text 
to which it pertains. But neither the Keep With nor the indenture of the 
alert can be determined unambiguously based solely on context. 
Consequently, two formatting attributes, KeepWith (values are Keepwithnext, 
Keepwithprevious, and Keepwithboth) and Indent (10 values) are required.

By adding the above-described formatting attributes to the EDD, I can 
resolve all of the ambiguities in the content model of Prcitem. A different 
set of elements and content models for process lists could have eliminated 
some, if not all, of these ambiguities, but that is not an option because 
instances produced by FM+SGML must conform to the ATA DTD. And, of course, 
since the formatting attributes I added to the EDD are not conformant with 
the DTD, I must drop them all on export to SGML. Which means that, when I 
import an SGML instance of the ATA DTD into FM+SGML, the formatting 
attributes are assigned their default values, and I must search for each 
such attribute, and, where necessary, change its value.

>Take FM SGML applications for example. Consultants
>throw around "application" as if it's some giant development project. 
>Cripes, it
>only means you have a template, EDD, DTD, and read/write rules.
The example I cited above to deal with the deficiencies and ambiguities in 
the content model of just one element in an existing ATA DTD explains why 
applications are often "giant development projects". Frequently, the only 
way an FM+SGML application can both properly format the information and 
successfully round-trip document instances that conform to an 
industry-standard or government DTD requires the development of API clients 
and other tricks and workarounds to cope with the lousy design of those 
DTDs, as well as the many significant limitations of FM+SGML.

And designing a complex EDD/DTD from scratch to successfully satisfy all of 
a client's needs (and quirks) for both structure and formatting is most 
definitely a major undertaking, which begins with performing a thorough 
content analysis of the client's unstructured legacy documents.


====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
177 Riverside Ave., STE F, #1151, Newport Beach, CA 92663
---Subscribe to the "Free Framers" list by sending a message to
majordomo@omsys.com with "subscribe framers" (no quotes) in the body.



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