Re: [FrameSGML] XML as native FrameMaker format, text insets, and DOCTYPE declarations

[Daniel Emory <danemory7224@xxxxxxxxxxxxx>]

While reading this email, the Burt Bacharach song
?What the World Needs Now? should be playing in the
background.

Hedley Finger?s problem is that he?s trying to use
structured FrameMaker in lieu of a Content Management
System (CMS). Lynne Price?s excellent reply points out
the severe limitations of FrameMaker for this purpose,
and suggests that an XML-based CMS ?can help manage
exactly? the kind of problem described by Hedley. But
she also points out that such systems are expensive. A
number of large companies, particularly in the
Automotive and Aircraft industries, which used
FrameMaker in the past, are opting for Documentum as
their enterprise-level repository of information. And
they?ve realized that FrameMaker simply doesn?t fit
well into a such high-end CMS environment. So let?s
take a look at what Documentum (and similar systems)
can do when all the bells and whistles are bolted on.

o The CMS is a repository of objects. Objects may,
among other things, be XML fragments, images, or links
between objects. Metadata (e.g., profiling
information) is attached as attributes to these
objects in the database. An individual ?document?
object might be an XML fragment containing service
information for a particular component of a system.
Documentum allows linking of such individual fragments
into virtual documents which are created on-the-fly in
response to a user query. It is imperative, therefore,
that, when such a fragment is edited, the change must
appear in every possible virtual document which can
contain that fragment.

o A set of web tools and servers. Documentum offers
WDK for this purpose. All profiling and searching is
done using the WDK interface. 

o A server that delivers retrieved content to users.
Docuenturm offers its 4i e-Content Server for this
purpose. 

o A fundamental requirement of such systems involves
standardized mechanisms and solutions. Version
handling, for instance is often a serious problem. The
solution must not only provide full version handling
and tracking, but also may have to address issues such
as lifecycles. 

o Another key element of the solution is out-of-line
links (i.e., links that are completely defined outside
the resources being linked, which is a fundamental
requirement for enabling practical information reuse
and managing the version dependency of information).
This kind of linking paradigm should use the W3C
extended Xlink recommendations. This approach also
makes conditional links much easier to create.

o Most importantly, such solutions require that there
be standardization of tools wherever possible, and
particularly that business logic be moved out of
editing and document management tools. Fundamentally,
this involves middleware containing an isolating layer
of business logic between the XML editor and the
database. This middleware should, among other things,
use the eXtensible Filter Objects (XFO) open source
development framework. This middleware will be used,
for instance, to customize the XML editor.The need for
standardized middleware for this purpose is what has
led many companies to replace FrameMaker with
Arbortext Epic Editor as the XML editor because,
unlike FrameMaker, it is designed to be easily
customized (using standardized middleware such as that
described above). However, specialized tools may still
be required for such tasks as creating diagnostic
trees, parts information in XML, or generating
printed-book--quality paginated output with running
header/footers, and perhaps also containing
hypertexted  cross-references, tables of contents, and indexes.

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