Re: [FrameSGML] Re: [FM+SGML] Forcing an attribute to have avalue

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 09:59 AM 4/7/00 +0100, Mark Barratt wrote:
>>   There is no reason for the r/w rules to provide this much
>> capability. After all, the FDK already provides a general-purpose
>> programming language interface into FM+SGML during import and
>> export. Nevertheless, there is a middle ground between arbitrary
>> processing and a direct everything in the SGML document must
>> correspond exactly to something of the same structure in
>> the FM+SGML representation. 
>
>The logic is good. The problem is, as you say, where to draw the line. I
>think my primary skills - like a lot of Frame users - are as a writer
>and - like not so many - as a typographic designer. I use Frame to make
>documents for paper and screen which are fit for purpose. Inevitably and
>increasingly, that means understanding and controlling the way the
>software behaves, which means in turn knowing some stuff that seems to
>me esoteric and complex.
==============================================================
On 3/29/99, I submitted the following FM+SGML enhancement request to Mark
Hilton of Adobe:
++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.

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