Re: FrameMaker Release 7.2

["Lynne A. Price" <lprice@xxxxxxxxxxxx>]

Steve,
  I am very tempted to argue that there is no need to hate FDK clients, 
but I'll restrain myself at least long enough to express my major point, 
which is:
  One way of categorizing the customization that is sometimes needed 
during import and export of FM documents from and to XML/SGML is to 
distinguish situations that are purely structural from those that require 
knowledge of FrameMaker formatting. Examples of the first include:

a) Alphabetizing items in a list
b) Using an element named Title for chapter and section titles, figure 
captions and table titles in XML; in FrameMaker, using TableTitle for table 
titles and Title for all the others
c) In XML, defining a Figure element to have an attribute that identifies 
an imported graphic file and specifying the caption as the content of the 
element; in FrameMaker, the corresponding Figure element has two 
subelements, Graphic for the graphic and Caption for the caption

Examples of the second include:

d) Changing the master page of a Section that fits on a single page
e) Setting a paragraph's font size to an arbitrary value specified as an 
attribute
f) Splitting tall table rows into multiple rows (using, of course, an 
algorithm specific to the content of the particular tables so that some 
sensible distribution of the content of all table cells is possible)

XSLT is often a reasonable tool for situations of the first type; it was 
designed specifically to perform such transformations of structure. It 
cannot help in situations of the second type because it cannot access 
FrameMaker page layout.

OK, that ends my restraint! Anyone who doesn't mind learning XSLT should 
certainly be capable of learning the FDK. The open-ended nature of generic 
markup means that a general-purpose programming language is sometimes 
needed to support the intended formatting of some element structures. When 
the processing depends on details of FrameMaker formatting, you either use 
the FDK or an FDK program such as FrameScript, or you complicate your 
workflow by transforming a temporary MIF file.

By the way, while the XSLT is an appropriate tool for structure-based 
transformations, it is not the only possibility. One consideration in 
choosing a tool is the skills of the people who are working on your 
transformation. While I will concede there are more XSLT programmers than 
FDK programmers around, there are probably still a lot more C programmers 
than XSLT programmers.

        --Lynne


At 04:48 PM 9/15/2005, Steve Whitlatch wrote:
> On Thursday 15 September 2005 04:11 pm, Lynne A. Price wrote:
>
> >    While it won't help with SGML, the 7.2 XSLT support for XML documents
> > comes very close to eliminating the need for an FDK client for XML
> > documents.
>
> Wow, that's the first I've heard of this. I _think_ it's good news. I have
> always hated "custom api clients" or "FDK clients" because I can't write
> them. I hate them badly. I really hate them.
>
> > Of course, you may have to write the XSLT transforms (two: one
> > for import and one for export) yourself, but conversion between FM index
> > markers and the DocBook index model is straightforward in XSLT, as is
> > condensing sequences of white space characters to a single space.
>
> This is reasonable, or good, I think. I am no wizzard with XSL (yet?), but
> putting the time and effort into getting better with XSL/XSLT/XSL-FO/XSL-HTML
> (all things XSL . . . including XPath, XQuery, etc.) is a good investment.
> I'll do it.


Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application development, 
and training
lprice@xxxxxxxxxxxx            http://www.txstruct.com
voice/fax: (510) 583-1505      cell phone: (510) 421-2284 



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