Re: Using FM+SGML Fragments (was: doc. in different languages)

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 08:05 AM 3/2/99 +1100, Marcus Carr wrote:
>-----------------------------Snip
>I believe that your situation may be slightly different to those who
require >full-scale dual language
>versions, in that your data (warnings, cautions, notes and document
references) >would tend to be more
>static than straight documents. Additionally, some of your references may
be >applicable to entire
>datasets, not specific to single documents. For these reasons, I would be
>trying to manage this
>information at the SGML level rather than leaning on an application. I
would >build parallel libraries of
>entities, one for Australia and one for one for NZ, and invoke them via a
>parameter entity in the DTD.
>I'm not sure what the workflow might involve for FrameMaker+SGML - you
could >invoke one of two
>applications calling different EDDs, but then you have maintenence issues
when >you update the entities.
>The alternative might be to create a preprocess that would resolve the
>entities, allowing you to use the
>same FrameMaker application and EDD. I'm not sure if this additional layer
>would constitute unacceptable
>overhead, but it would accomplish what you desire without leaning too hard
on >FrameMaker - after all, you
>must be using it pricipally as a pagination engine, aren't you?
>------------------------Snip
===============================================================
Yes, a pagination engine is all you could use FM+SGML for under this
approach, and that's unfortunate, because the ideal way to create, edit and
maintain these fragment libraries would be in FM+SGML fragment files, where
each note, caution, warning, or document reference would be placed in a
separate text flow. Each such text flow would then have to be independently
exported to SGML as an SGML SDATA entity, and these entities would be
invoked as external parameter entities in the DTD.

When importing into FM+SGML an SGML document instance containing references
to those SGML SDATA entities, the read/write rules would convert the
parameter entity references to the corresponding imported-by-reference text
insets in the read/write rule-specified text flow of an FM+SGML fragment
file. On export to SGML of an FM+SGML document containing such
imported-by-reference text insets, each text inset would be converted by
those same read/write rules to the applicable external parameter entity
reference in the resulting SGML document instance.

It would still be necessary, however, to export each such text inset from
the FM+SGML fragment file as an SGML SDATA entity having the filename
specified for that entity in the DTD's external parameter entity
invocations. Unfortunately, this won't work, because, on export, FM+SGML
creates from each text flow an SGML document instance (with DOCTYPE
declaration) instead of an SGML SDATA entity. The only way to make it work
would be to use some tool to strip out the DOCTYPE declaration from each
such exported file so as to convert it to an SGML SDATA entity.
     ____________________
     | 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.   **