Re: A FrameMaker Solution to the XML Problem (Long)

[Daniel Emory <danemory7224@xxxxxxxxxxxxx>]

--- Kevin Farwell <kevinf@xxxxxxxxxxxxxxx> wrote:
> As a FrameMaker user for twelve years, six of those
> in structured 
> FrameMaker, and a user of XML for five, I have to
> address what I see 
> as misleading information. The two paragraphs below
> capture the 
> criticisms of XSL and Formatting Objects. I'll
> address specifics.
===============================
You argue that my statements and those of Jeremy
Griffith were "misleading." You maintain that all of
the things which Jeremy and I stated were "unlikely
that XML tools could ever do successfully" what
FrameMaker does so effortlessly. 

The operative word was "successfully." Claims similar
to what you are making about XML formatting tools were
also made about the old DSSL/FOSI tools for SGML. The
reality was that there were few, if any
implementations of those old tools which actually
achieved the kinds of claims you ar making, simply
because the cost of development was astronomical. 

The word "successfully" in the context I and Jeremy
used it did not mean "not possible," it meant "not
economically feasible," Not feasible also because tech
pubs departments frequntly want to make evolutionary
improvements in their documentation. Most such changes
can be easily implemented in FrameMaker simply by
making changes in the template. But such changes
become so costly when thay must be implemented with
XSL and formatting objects that most proposed
improvements will be shot down as economically
unfeasible. In other words, once an XSL/formatting
object application is developed, its outrageous cost
means that, for all practical reasons, it is locked
permanently in stone, thus evolutionary improvements
are prohibited.

The fact is that most tech pubs departments, even
large ones, don?t have anyone on their staff who are
experts in developing XML formatting solutions. That
means they must turn either to corporate IT weenies or
ouside consultants for development, and there?s a high
likelihood of failure. And once they go down that
road, the tech pubs department must continue to rely
on outside help each time they find a glitch, or a
need for changes. This generally results in a whole
lot of time-consuming handwaving, with neither party
knowing what the other is trying to say.
===============================
Among other things, you claim that generated lists and
indexes with page numbers and hypertext links could
somehow be produced using XSL tools. Below, for
instance is the reference page for generating a table
of contents in structured FrameMaker:

<$elemtext>	<$chapnum>-<$pagenum>
<$elemtext>	<$chapnum>-<$pagenum>
<$elemtext>	<$chapnum>-<$pagenum>
<$elemtextonly>	<$pagenum>
<$elemtextonly>	<$pagenum>
<$elemtextonly>	<$pagenum>
openObjectId <$relfilename>:<$ObjectType> <$ObjectId>

Now, why don?t you describe in some detail what would
be required using XSL tools to produce a paginated,
hypertexted table of contents. Then proceed similarly
to describe how a hypertexted, paginated multi-level
index would be implemented with those tools.
===============================
You also state that 
"Page layout: Again, I'm not quite clear on what
choosing page layouts means, but if it means using a
specific layout for first pages, right pages, left
pages, blank pages at the end of a chapter, front
matter pages, TOC changes, index pages, etc., then XML
and XSL-FO are quite capable".

To evaluate the feasibility of using XML and XSL-FO
why don?t you describe in some depth what it would
take to accomplish this task, which is so effortlessly
simple in FrameMaker.

What about landscaped pages which are rotated in the
printed output? How would Formatting objects take care
of that, and, if it can be done, what exactly would be
needed (described in some detail) for formatting
objects to detect their presence and rotate the page. 
=====================================
You also state that 
"Complicated headers and footers, those with chapter
name, manual name, page numbers, the text of the
nearest header (measured forwards or backwards), used
in conjunction with the page choices listed above, can
be created with XSL-FO. Correct page numbering: As
part of the header and footer capability listed above,
FO processors can count pages, starting over at
chapter breaks, numbered from front to back, etc." 

Typically, running header/footer variables are used in
FrameMaker for this purpose. An extreme example of
heavy use of these variables can be found, for
example, in ATA publications. Are you prepared to
claim that such complex running headers derived from
FrameMaker variables are replicatable using XSL-FO,
and if so, why don?t you describe in some detail how,
exactly that would be accomplished by XSL-FO.
==============================
I mentioned complex tables. Such tables might include
rotated column headers, custom ruling and shading,
controlling whether text in a table cell appears at
the top, middle or bottom of the cell, and other types
of customization. 

Your response was:

"Complex tables: I'm not sure what "complex" means,
but if it means controlling shading, ruling, row
height, column width, spanning cells over columns or
spanning cells over rows, then XML and XSL-FO handle
it just fine."

Once again, the meaning of "just fine" in terms of
what it actually takes to accomplish it would be
necessary to determine whether it?s feasible when
there are many different types of tables with many
different types of customization within a document.
===============================================
You state that:

"Autonumbering: Applying numbers and bullets to lists
or objects like figures or tables is actually a huge
strength of XSL. I have done some enormously
complicated lists with XSL".

When a structured document chunk containing numbered
titles for headings, tables, figures etc. is extracted
from a large document for delivery to a user, it is
often nesessary for the actual numbering that exists
within the document as a whole be preserved when the
chunk is delivered. Such preservation is possible when
each level of the number is provided in a separate
attribute (as is done in ATA documentation).
FrameMaker uses prefix rules to produce the complete
number, and the numbering is preserved when a chunk is
extracted for delivery to a user. Similar requirements
exist when, for instance, information is extracted
from regulatory or legal documents, where the correct
number is crucial. Why don?t you explain in some
detail how this requirement would be achieved using
XSL.
===========================
Finally, you state that:

"Now that I do most of my work in XML, it's painful to
go back to DTP applications"

Please explain how things that FrameMaker does
effortlessly is more painful than trying to replicate
them with XML tools? I find that claim profoundly odd.
========================================
I leave to Jeremy Griffith the response to your claims
about successfully converting XML to RTF and other
formats using XSL/XSLT.


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