RE: FrameMaker Release 7.2

["Steve Whitlatch" <swhitlat@xxxxxxxxxx>]

>    While we'll all have to wait to see the documentation that comes with
> the new release, I expect there will be documentation on how to invoke XSLT
> from FM but nothing documenting XSLT itself. After all, XSLT is something
> that you will now be able to use with FM but since it exists outside of FM
> it should be documented outside of FM.
>
>          --Lynne

I don't think anyone expects FrameMaker to include general documentation on XSL,
especially if FrameMaker's new XSL capabilities are just a GUI mechanism used to
trigger Saxon, Xalan, or some other XSL transformer.

For those reading who are unfamiliar with XSL transforms, in the very simplest
sense I would describe it as a re-tagging, re-naming, and re-arranging of
content, with the option to drop content or create and include new content
and/or structure. Transforming XML from a custom DTD to HTML is one example. In
that type of transform, one has the custom XML DTD to exactly specify one model,
and an HTML spec specifies the other model.

If interested, a simple custom XML DTD and its corresponding XSL used for an
XML-to-HTML transform is here:

DTD
http://www.getnet.net/~swhitlat/XML/Essay_DTD.html

XSL
http://www.getnet.net/~swhitlat/XML/Essay_XSL.html


So, if we are to transform XML to/from FrameMaker, there is a FrameMaker model?
No?

Documentation for that model is what's needed, more than what was supplied with
version 7.1. Examples and such.

Also, open question to anyone at all. Given a FrameMaker book, and of course by
"book" I mean that it includes all the usual generated lists (TOC, LOT, LOF,
Index, etc.), how does one prevent FrameMaker from exporting these generated
lists as part of the XML tree? Is there some read/write rule for it? It is
reasonable to expect FrameMaker to be smart enough to know not to do that.
FrameMaker should be able to identify its own generated lists and it should know
better than to inject that data into the exported XML. It certainly isn't there
upon import. But it appears that one must control this behavior explicitly. How
is that done? If the answer is "post-processing," then the answer is that
FrameMaker supplies nothing for that. Any kind of post-processing or
pre-processing (whether with XSL, perl, sed, or whatever) is a burden on the
author/developer/administrator, regardless of whether FrameMaker provides a
trigger mechanism.

Thanks,

Steve Whitlatch




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