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

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

I have copied Bill Hall (who initiated this thread), in case he's not
subscribed to this list.

Dan Emory wrote:

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

I believe that what you describe above implies that FrameMaker+SGML should
behave as a document management system. The ability to modify the value of an
external entity suggests that the new value is applicable to all documents that
use it - an assumption that FrameMaker+SGML can't possibly be expected to make.
For this reason, I would abstract fragment management one level up the process.

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

In the case where the fragments are applicable to a single document that would
be ideal (though you then probably wouldn't benefit from using entities
anyway), but when the same fragment needs to be referenced by an entire
dataset, you might be wary about allowing the writer of a particular document
to reset the values in the context of the current document.

I would set up a single FrameMaker+SGML application and feed it normalised
data, by preprocessing the text of the entities into the data. By doing this
via the API, this would involve a conceptual command along the lines of
"Process [filename] for [audience] and load the resulting file with [fmapp]".
Using [audience] rather than [language] is just a further example of abstaction
- perhaps there could be a case made for different information to be produced
based on user level. I would prefer not to burden FrameMaker+SGML with this
functionality because (a) it is an information management issue, not a document
production issue, and (b) using such a sophisticated feature of any application
is likely to limit the portability of the documents more than the addition of a
new layer would. SGML is not a complete solution if you trap yourself into
using a particular application.


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