Re: FM+SGML Enhancement Request No. 3

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:54 AM 4/5/99 +1000, Marcus Carr wrote:
>
>Dan Emory wrote:
>
>> 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.
>
>I'm not sure that moving functionality from the FDK to the read/write rules
is going
>to result in a net simplification - in some cases, I'm fairly sure that the
opposite
>would be true. I see the read/write rules as being somewhat the domain of the
>"technical user", but the FDK as being well and truly "programmer/developer"
>territory. Why do you feel that this is unsatisfactory?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The person you call the "technical user" who writes the read/write rules is
also probably the same person who develops the format rules in the EDD.

In the EDD, he can write a format rule of the form:

1. If context is List[Type = "Bullet"]
        Numbering Properties
                Autonumber format \b\t
   Else, if context is List[Type = "Numbered"]
        1.1 If context is { first }
                Numbering Properties
                        Autonumber format: <n=1>\t
             etc. etc.

It would certainly be no stretch for that person to employ a similar
conditional construct in the read/write rules to evaluate attributes for
the purpose of determing how an element should be processed on import or
export.

More importantly, unlike API clients, read/write rules can easily be
modified on an ad hoc basis to comment out inapplicable rules for a
particular import/export operation, or to modify a rule for a particular
situation.

Frankly, I'd be satisfied if the next FM+SGML release just allowed the
evaluation of attributes in read/write rules. The other things I proposed
are secondary, and would, admittedly, complicate things a bit. In any event,
those who might feel intimidated by such constructs can still resort to an
FDK developer, but many "technical users" would regard such constructs as a
piece of cake.

Moreover, I don't regard the capability to evaluate attributes in read/write
rules to be an effort to move functionality from the FDK. That functionality
should have been in the read/write rules in the first place, thus I'm
proposing to move it back where it belongs. The use of attributes whose sole
purpose is to control import/export (e.g., on an individual bases to specify
whether a particular graphic should be written out on export, and if it is
written out, the format in which it is written) would be a powerful new
feature of FM+SGML.
     ====================
     | 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.   **