RE: Reading the runes

[Larry Kollar <Larry.Kollar@xxxxxxxxxxx>]

"Hogan, John T. (ESA)" wrote:

>> I'm assuming a *unidirectional* flow:
>>
>> 	FM -> XML DB -> presentation

>A unidirectional workflow may be OK as a quick-start but it's not attractive
>or efficient as a long term process because it requires maintaining multiple
>masters.

If you consider the intermediate format a "master," yes.

>> If you're assuming that the back end (i.e. the presentation side)
>> is driven by XSLT, you don't even have to parse out the pieces --
>> retrieve a document, let the transformation weed out what isn't
>> needed, convert the rest to the proper presentation format.
>>
>> This approach has several advantages:
>>
>>   - You create content using your current authoring tools (and
>>     if you have to change something, you do it there & re-export).
>>
>...
>*******************************************************************
>When we needed a quick-start a few years ago, we created a similar workflow
>using Frame/Word/QuickSilver to create a web-accessible database of PDF
>documents. ... What we really wanted then and are
>still trying to develop is a workable way to store reusable master text and
>graphics only once. We want to generate all needed deliverables from the
>masters without having to maintain separate storage of an "original" for
>editing and revision. SGML/XML is the logical choice for text masters but
>the bidirectional limitations of FrameMaker make it an increasingly
>"ungraceful partner" in this dance.

People *do* use FM+SGML for round-tripping. Getting it set up often
requires an (expensive) outside consultant though. If using a
generalized SGML tool (or XML tool, for that matter) were easy, I
suppose that everyone would be doing it.

Case in point: while rewriting a large complex document, we came up
with the idea of using text insets to show a command's location in
the internal tree structure. Doing a straight export to SGML, this
would end up as a *graphic* -- which is not how I'd prefer to do it.
A consultant would (I hope) be able to fix the read/write rules so
that the inset gets exported as part of the flow.

Is this FrameMaker's fault? Sure. I won't ever say FM is perfect.
Is there a workaround? Probably.
Are there better alternatives? (cue crickets chirping :-)

>FrameMaker 6 ... added nothing to improve the process of
>creating/editing/revising fragments in the SGML/XML database
>and it is downright inappropriate for assembling/printing/
>transforming the stored fragments for delivery.

Again, I think that this is a job for an outside consultant.
First, *are* you using a database? If so, which one -- Oracle?
Interbase? Ingres? Informix? Berkeley DB? And what does each
record look like? Should we seriously expect FrameMaker to
support each and every instance out of the box?

While that would be unwieldy, Frame *does* have hooks built in
so you can have someone add the capability you need. In fact,
if the database is simple enough, I could probably script it
myself using AppleScript (and appropriate r/w rules) on the
client and Perl on the server. Hmmm. I'll have to try that if
I get some spare time....

Which brings me to my final point: a lot of us are working on
Internet time now. I agree with those who say Frame ought to be
doing this-and-such, but in the meantime I have to get stuff
done.

	Larry
	Some see things as they are and ask "why?"
	Bobby Kennedy saw things as they could be and asked "why not?"

	I see things as they are and say "hey, we can do some neat
	stuff with this...."



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