[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

RE: Reading the runes



> -----Original Message-----
> From: Larry Kollar [mailto:Larry.Kollar@arris-i.com]
> Sent: Thursday, November 02, 2000 3:30 PM
> To: Dan Emory; framers@omsys.com
> Subject: Re: Reading the runes
> 

...

> I'm assuming a *unidirectional* flow:
> 
> 	FM -> XML DB -> presentation
> 
> 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).
> 
...
*******************************************************************
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.

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. FrameMaker+SGML also helped us meet near-term contract
requirements for "SGML deliverables". 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.

FrameMaker 6 enhanced the old book interface but 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. Your point about the diminishing importance
of WYSIWIG sounds right but it also argues against FrameMaker. So far,
FrameMaker's only stake in the process is as a WYSIWIG SGML authoring tool.
Subtract the need for WYSIWIG editing and what does FrameMaker bring to the
dance? If FrameMaker+?ML 7 improves the round-trip functionality it may be a
more attractive partner.

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