Re: FM5.5.6+SGML(W): Inflexible graphic element.

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:37 AM 4/22/99 +0100, Richard Higgins wrote:
>Hello:
>The default FM translation from SGML for a graphic element seems to
>allow only for the creation of an empty element, with certain
>"attributes" and no children.
>
>My DTD allows for caption text either as an attribute of the graphic
>element, or as a child element of the graphic element.  Am I toiling in
>vain (other than for the good of my soul) trying to work out a way to
>get either of these to translate into the FM document, or does anyone
>know a way to haul them in?
-+-+-+-+-+-+-+-+-+-+
This is a fundamental flaw in FM+SGML. It's common for DTDs to specify that
graphics can have mandatory or optional children, but you cannot have a
general rule for a graphic element in an FM+SGML EDD, thus:

        On import to FM+SGML, the child caption element is invalid, AND

        On export to SGML, the graphic element is always written
        out with a content of EMPTY, thus the graphic element will
        not conform to the DTD.

There is no way to use the caption attribute in the graphic element to
create the caption text (e.g., using a prefix or suffix rule in an
EDD-defined Caption element), because the attribute must be in an ancestor
element, and the graphic element cannot be the ancestor of anything.

There is no way to use read/write rules to modify the structure in the way
that would be needed on import and export, since the only available
structure-modifying rules are Unwrap and Drop. 

Note also that the same situation applies to equation elements in FM+SGML.

Since the structure must be modified (on both import and export) in ways
that are not possible with the existing read/write rule capabilities, you
have two choices.

1. Modify the EDD to create a wrapper element that has the graphic and its
child caption element as the children of the wrapper element. Then, using
the FDK, write an API client that:
        On import to FM+SGML wraps the graphic and caption elements as
        siblings of the EDD-defined wrapper element.

        On export to SGML, unwraps the EDD-defined wrapper element, and
        writes out a non-empty graphic element with its child caption
        element.

It's problematic whether such an API client could even be written.

2. Modify your DTD to add a wrapper element that contains the graphic and
caption elements as its children. Obviously, this change would invalidate
any existing SGML document instances produced with the earlier version of
the DTD.  
     ====================
     | 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.   **