FM+SGML Enhancement Request No. 3

[Dan Emory <danemory@xxxxxxxxxxxx>]

ENHANCING THE POWER OF READ/WRITE RULES
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.

CASE 1: 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;
}

The default choice for the ExpType attribute could be specified as
        Do Not Export
which handles the case where an SGML-compatible graphic is imported by
reference, and does not have to be written out on export to SGML.
Consequently, authors would have complete control over whether the graphic
is written out, and, if it is written out, the format in which it is written. 

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.

CASE 2: Consider the following situation where the context of an element, as
well as its attribute values, determine what FM+SGML element you want to
equate the element to 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" {
        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") {
                                is fm element "abc";
}
                        ELSE IF (attribute "whatever = "Choice2") {
                                is fm element "def";
}
                        ELSE {
                                is fm element "ghi";
}
                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.

CASE 3: 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 an attribute named HTML whose value was
EDD-specified and Read Only. This attribute would identify the equivalent
HTML element for each FM+SGML element. Then, if the appropriate read/write
rule constructs shown below were added, any structured FM+SGML structured
document could easily be exported as HTML through the use of that attribute.

This, however, would require a modification of the 1 to 1 relationship that
currently is required between SGML elements and the corresponding FM+SGML
elements. For example, suppose the conversion attribute were named "HTML":

fm element "xyz" {
        Writer }
                export as element "^HTML"
}}
Where the caret symbol (^) indicates that attribute HTML is to be
replaced by its value.

The method described above would permit many different FM+SGML elements to
be equated to the same HTML element.



     ====================
     | 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.   **