Re: FrameMaker+SGML (or Structured FM7) EDD and R/W rules Management

[eric.dunn@xxxxxxxxxxxxxxxxxxxxxxxxxxx]

Lynne,

Thought a little praise would bring you out of the woodwork. ;-) Actually
figured you would be one of the few (or perhaps the only one) that might
contribute to this thread.

<<It certainly should be possible to allow r/w rules anywhere that Comments are
permitted in my meta-EDD. From the EDD perspective, they would just be
documentation elements. In fact, you could have a r/w rule EDD that treats the
EDD elements as comments (by putting comment delimiters: /* and */) around them.
Then you can switch between an EDD and r/w rules simply by importing element
definitions.>>

That might be a valid approach, but it wasn't what I was envisioning. It would
certainly be easier than what I was envisioning though. I would think that it
would be worthwhile to go to the lengths of creating an EDD that included the
R/W rules not as comments but as the actual R/W rule elements in the positions
that they apply. Element rules after the General Rule, Attribute rules in the
Attribute definition, applicable Property rules in the correct elements. Add
required "general rules" holders that could be placed at the same level as
elements and sections in the EDD.

This UberEDD would be unreadable by FM as either EDD or R/W. The UberEDD would
be saved to SGML using four separate R/W rules and processes.
1 - UberEDD as-is saved as SGML for use in a CVS type system.
2 - UberEDD stripped to R/W rules. This SGML file is then read into FM using the
correct application to create a valid R/W file.
3 - UberEDD stripped to EDD. This SGML file is then read into FM using the
correct application to create a valid EDD file. EDD is then saved as DTD. EDD is
imported into template file.
4 - UberEDD stripped to Application File. This SGML file is then read into FM
using the correct application to create a valid Application file.

<<Since there are no comments in the structure application file (SGML
application file in pre-7.0 versions of FM+SGML), the same technique won't work
for maintaining application definition information in the same file.>>

This actually is what gave me the idea for #4. I was actually only thinking of
having the template location identified in the UberEDD so that the Template
could automatically be updated with the new EDD.

<<Since there are much fewer element types in the application definitions than
in EDDs or r/w rules, I'd assign one condition tag to the entire document, and a
second condition tag to the application definitions. Then I'd hide the first
condition and show the second. The result should be an application definition
you can reread.>>

Actually I was toying with the idea of using conditional text to allow for
differences between and multiple versions of DTD, EDD, and so forth. Perhaps a
solution using attributes to identify required contexts. After all, if the
read/write rules are to drop attributes or elements these elements and
attributes shouldn't be present in both the EDD and DTD. For the differences, I
was thinking an attribute (or element) for InEDD and InDTD. The conditions for
the differences would have to be processed somewhere in the process #3.

Eric L. Dunn

PS: I will assume that you will not be reading this post until after your long
weekend. Hope you have/had an enjoyable 4th of July. Here in Quebec we just had
2 long weekends in a row, so it's hard to be jealous.



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