Re: FrameMaker Release 7.2

[Steve Whitlatch <swhitlat@xxxxxxxxxx>]

On Friday 16 September 2005 12:12 am, Lynne A. Price wrote:

>    I am very tempted to argue that there is no need to hate FDK clients,

You are right, and I have purposely been overly dramatic. That FDK clients are 
an important part of a structured FrameMaker application is, in my opinion, 
both good and bad. Of course, FDK clients are good because they extend 
structured FrameMaker's capabilities. But they are bad because FrameMaker 
needs the FDK clients to do too many things.   

I've listened to Linux kernel programmer conversations in which, when one was 
asked to explain something, the final reply after attempting more detail was 
"it does the right thing." That reply was accepted and understood. The 
meaning was that under all the possible gazillions of conditions that might 
occur, the code did what was expected with no harmful side affects.  I got 
the impression that "it does the right thing" is an often-used phrase. 

Of course, that is what I want from FrameMaker, without the need for an FDK 
client. I want FrameMaker to always "do the right thing." It is too much to 
ask, yes, because I want that without having to actually write the code that 
makes the right thing happen.

Your posts are always of the highest value. I'll try to learn from what you've 
written, and if I get the time I'll put some effort into learning to write 
FDK clients. But for now, the new XSL import-export capabilities in 
FrameMaker have my attention. Can you tell more about these new capabilities? 
Yes, I still want to eliminate the need for an FDK client completely. Can you 
shed any light on what that might take for DocBook XML. 

Also, do you know if these new XSL import-export capabilities are well 
documented? I need good documentation. My background is in technical writing, 
not programming. I only program when I must.

Do you think it's possible to create a FrameMaker DocBook XML project without  
using any FDK at all, just using the new XSLimport-export capabilities? I am 
mostly concerned about maintaining validity throughout (import, while 
authoring, and export). FrameMaker's automated formatting upon import is very 
nice, but for me it is secondary to validity issues.    

While I have your attention, is there a read/write rule that prevents 
FrameMaker from including the unstructured files of a FrameMaker book (TOC, 
LOT, LOF, etc.) into the exported XML tree.

Thank you for all your help. 

Steve Whitlatch
   

> 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.   **