FM+SGML Enhancement Request No. 3

[Dan Emory <danemory@xxxxxxxxxxxx>]

THE PROBLEM: In the existing read/write rules, there are no mechanisms for
evaluating the context of an element, or the value of an element attribute,
and then specifying the import or export action to be taken based on the
evaluation outcome.

THE PROPOSED SOLUTION: The addition to the read/write rules of a conditional
processing construct, combined with the ability to declare and set
semi-persistent read/write rules variables, would aliminate most of the
problems that must now be resolved by developing expensive (and difficult to
modify) import/export API clients using the FDK.

The ability to perform such evaluations, particularly on attribute values,
is a vital missing ingredient in FM+SGML. Suppose, for instance, an
all-purpose graphic element, GRAPHIC, had both an entity attribute and a
choice-type attribute named ExpType that the user sets to specify what
graphic type to produce on export to SGML. The entity attribute specifies
the name of the entity to be put in the entity declaration produced in the
SGML declaration, and also specifies the stemname to be assigned to the
exported graphic file.

Then, if there were a conditional processing construct available in the
read/write rules repertoire, you'd be able to write subrules such as this
under the GRAPHIC element:

    Conditional Processing {
        IF (attribute "ExpType" = "CGM") {
            writer {
		facet default {
			convert referenced graphics;
			export to file "$(entity).cgm" as "CGM";
}
	               	anchored frame {
		              export to file "$(entity).tif" as "CGM";
}}}}

        ELSE IF (attribute "ExpType") = "TIFF" {

etc., etc., etc.
}}}}
    End Conditional Processing;
}

In the case I cited above involving graphic export, I presently have either
of two unpleasant choices to make because of the lack of a conditional
processing construct in the read/write rules repertoire:

1. Use the FDK to develop an API client to perform the conditional processing,
        OR
2. Create a different graphic element for each export format--such as:

        GPHC_EXP_TO_CGM
        GPHC_EXP_TO_TIFF
        etc., etc., etc.

Consider the following situation where the context of an element, as well as
its attribute values, determine what action you want to accomplish on import
to FM+SGML:
/* Declare a read/write rules variable named "context".
 */
declare rwvar "context";
/* On import, determine how fm element "abc" will be imported, based on its
context, and the value of attribute "whatever".
 */
element "abc" is fm element "ABC" {
        attribute "whatever" is fm choice attribute "Whatever";
        reader {
                reset rwvar "context"; /* resets the rwvariable. */
                Conditional Processing {
                        IF (parent element is "pqr") AND (next element is "stu"{
                                SET rwvar "context" to "case1";
}
                        ELSE IF (some other context expression) {
                                SET rwvar "context" to "case2";
}
                        ELSE {
                                SET rwvar "context" to "case3"
}
                End Conditional Processing;
}}
                Conditional Processing {
                        IF (attibute "whatever" = "Choice1") AND
                         (rwvar "context" = "case1") {
                                DO THIS ON IMPORT;
}
                        ELSE IF (attribute "whatever = "Choice2") {
                                DO SOMETHING ELSE ON IMPORT;
}
                        ELSE {
                                DO SOMETHING DIFFERENT ON IMPORT;
}
                End Conditional Processing;
}}
                reset rwvar "context";
}}

The first rule declares the rw rules variable "context" for use in
determining how to import any SGML element. The first rule under reader
resets variable "context" to null in preparation for the conditional
processing that follows. The last rule under reader resets the rwvariable
"context" to null in preparation for processing the next element, whatever
it is. If the last rule were omitted, the value of rwvariable "context" that
was set in the processing of element abc would persist during the processing
of the next element, and that value could (optionally) be used in the
conditional processing of any subsequent elements until an element is found
in which a reader subrule resets the variable to null. Thus, the same
rwvariable, "context" could be used in many different ways in the processing
of each element where it is needed.

Conditional statements (IF, ELSE IF, ELSE) could be nested to any level, and
would include boolean, arithmetic, and comparison operators.

One powerful use of conditional processing would be to solve the dilemma of
exporting/importing conditional text. If an element had an attribute named
"Conditional", and that attribute were set to indicate a conditional tag,
then it and all of its children (if any) would be treated as having that
tag. Then, with conditional processing implemented as described above, the
read/write rules could specify whether or not the conditional element (and
its children) would be dropped on import or export.

And, of course, FM+SGML could offer a much more powerful and relaible way to
produce HTML than FrameMaker's present bug- and deficiency-ridden HTML
conversion filter. Suppose, for instance, that each element in an FM+SGML
document had attributes whose values were EDD-specified and Read Only. These
attributes would identify the equivalent HTML element, and specify the HTML
style to be applied to it. Then, if the conditional processing feature
described above were added to the read/write rules, any structured FM+SGML
structured document could easily be exported as HTML through the use of
these attributes.

     ====================
     | 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
10044 Adams Ave. #208, Huntington Beach, CA 92646
---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.   **