[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: "'Larry Kollar'" <Larry.Kollar@xxxxxxxxxxx>, framers@xxxxxxxxx
Subject: RE: Reading the runes
From: "Hogan, John T. (ESA)" <john.hogan.tempe@xxxxxxxxxxxxx>
Date: Fri, 3 Nov 2000 08:48:30 -0700
Sender: owner-framers@xxxxxxxxx
> -----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. **