[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: Daniel Emory <danemory7224@xxxxxxxxxxxxx>
Subject: Re: FrameMaker Release 7.2
From: Steve Whitlatch <swhitlat@xxxxxxxxxx>
Date: Tue, 13 Sep 2005 14:29:20 -0700
Cc: Framers List <framers@xxxxxxxxxxxxxx>, Free Framers List <framers@xxxxxxxxx>
Delivered-to: jeremyg-freeframers:org-ffarchiv@freeframers.org
In-reply-to: <20050913204654.55932.qmail@web81208.mail.yahoo.com>
Organization: Steve Whitlatch, Inc.
References: <20050913204654.55932.qmail@web81208.mail.yahoo.com>
Reply-to: swhitlat@xxxxxxxxxx
Sender: owner-framers@xxxxxxxxx
User-agent: KMail/1.8.2
Thanks for sharing your thoughts. I am hopeful about the new 7.2 release, but it is good to maintain perspective. I am most interested in whether the DocBook Starter Kit's DocBook custom API client has been updated. The previous one (Frame 7.1) is approaching an age of nearly ten years and has not been functioning well. > It's also unclear what the new XSLT support is all > about. Yes, because it is possible to include (or not include) so much of what XSLT can do, I will need to use the new release myself in order to determine how the new XSLT capabilities can help. > The most fundamental question is whether FrameMaker > 7.2 will deter Frameusers from moving to something > like the extremely robust Arbotext solution? The Arbortext solution is virtually all open-source under the hood, which may be difficult to believe considering the price. I am not saying that is all there is to Epic Editor, it is much more; nonetheless, Epic Editor is essentially and fundamentally an SGML/XML-to-Tex translation system. Amazing but true. Details available from Arbortext support, any Epic Editor installation, or the experts often found answering questions on the Arbortext Adepters mailing list. I still really like FrameMaker for its easy-to-use WYSIWYG edit view, and it is much easier to create a FrameMaker XML project than it is to create a new , custom "doctype" in Epic Editor. Additionally, it is difficult and expensive to create anything like a WYSIWYG edit view in Epic Editor, even if creating the FOSI with Arbortext's Styler product. FrameMaker is much, much better with respect to the end-user experience and what's seen on the screen. Sometimes, GNU Emacs and the command line beats everything because it is such a stripped-down solution that directly addresses whatever I need to do. It is a case of less being better. Steve Whitlatch On Tuesday 13 September 2005 01:46 pm, Daniel Emory wrote: > Fundamentally, the Adobe release does not offer enough > detail regarding the extent of the support for XML > Schema and XSLT to know whether it represents a small > or big step in the right direction. And, as far as the > "built-in conversion tools" for converting > unstructured docs to structured ones conforming to > some pre-specified target EDD, DTD or Schema, I > suspect they're not capable of much more than putting > lipstick on the pig, particularly if the pig (i.e., > the unstructured docs to be converted) were designed > and implemented well before any requirement for > conversion to structured docs was seen as a future > requirement. In such documents it is often found that > a given paragraph tag, character tag, marker type or > variable name must, in different structural contexts, > be mapped to different elements in the target > EDD/DTD/schema. If this problem of one-to-many > relationships is not addressed by the new conversion > tools, then there's not much added value. In other > words, if all the conversion tools do is fill in the > first column of the conversion table, not much has > been gained. > > It's also unclear what the new XSLT support is all > about. Can it, for instance, convert EDD Element > Paragraph tags and format rules which modify that > paragraph tag in different contexts, does the new XSLT > support permit you to produce style sheets (cascading > style sheets or XSL style sheets) derived directly > from the EDD-defined element paragraph tags, and > format rules, even when some formatting instructions > are derived from element attributes?. > > There's even more to it than that, including XML > formatting objects, and whether FrameMaker's support > for Schema is robust enough. And what about Unicode > support? > > The most fundamental question is whether FrameMaker > 7.2 will deter Frameusers from moving to something > like the extremely robust Arbotext solution? I doubt > it based on what limited information has been released > by Adobe. In fact, if it were a major step forward > toward full XML support, I'm sure the new version > would not be another point release. > > What it all comes down to is whether 7.2 is the end of > the line, at least for several years, or whether Adobe > intends to go much farther in future releases within > the next year or so. > > > Dan Emory & Associates > FrameMaker/FrameMaker+SGML Document Design & Database Publishing > DW Emory <danemory7224@xxxxxxxxxxxxx> > > ** To unsubscribe, send a message to majordomo@xxxxxxxxx ** > ** with "unsubscribe framers" (no quotes) in the body. ** ** To unsubscribe, send a message to majordomo@xxxxxxxxx ** ** with "unsubscribe framers" (no quotes) in the body. **