Re: FM+SGML Enhancement Request No. 3

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Dan Emory wrote:

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

To be honest, I don't really think that the read/write rules are adequate either,
but I suspect that the problems might be terminal. I heard a rumour way back in the
FrameBuilder days, that Frame Technologies were evaluating OmniMark with a view to
using it as the manipulation language. (They do look somewhat similar...)

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

True, though that can be a double-edged sword as it shifts the focus away from the
dataset and onto the individual instance. Sometimes situations that could be fixed
in the way you describe above should really be addressed by taking a global look at
the dataset, not by tweaking the rules used to import the documents. In the
scenario that we're discussing these tasks would likely be managed by two different
people.

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

It would, but if the read/write rules aren't up to the task, then you should use a
tool that is more appropriate. If you consider that SGML is the constant on both
sides and that FrameMaker+SGML is nothing more than "an application that does
something with SGML", then it isn't unreasonable for it not to support the myriad
of different ways that you might process a document for the purpose of the
application. This is an issue that we've discussed previously - I prefer to
externalise the problem and deal with it by applying a powerful tool at both ends
of FrameMaker, whereas you want a more self-contained processing environment. I
doubt if we'll ever convince the other of our respective opinions, but I would say
that my approach appears more flexible - if a better tool comes along, then I'll
start using it. On the other hand, if Frame were to drastically modify their
support for the read/write rules, you might be inclined to take your housebrick
collection for a swim off the end of the Huntington pier.


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



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