[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

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



--- Kevin Farwell <kevinf@xxxxxxxxxxxxxxx> wrote:
> Below you have several challenges and I'm not 
> inclined to engage them. Of course certain things 
> are easier in FrameMaker, and some are not. You 
> also salt in some incendiary words like 
> "astronomical" and "outrageous" which bring me 
> back to my original point that you're trying to 
> mislead. We still haven't arrived at a discussion 
> of a business case.
===========================================
I have never stated that I have a negative attitude
toward XML. I'm a firm believer in CMS as the ultimate
solution to document management, and XML is a crucial
component of such systems. The whole problem with both
SGML and XML is how to restore proper formatting and
page layout when instances are delivered to users.
DSSLs, FOSIs, XSL and XML-FOs may appeal to propeller
heads, but it makes no sense to use them if there's
another, simpler way. 

Structure, metadata and storage in a non-proprietary,
database-compatible format are fundamental
requirements of database-driven content management
systems. But since SGML emerged 20-some years ago, the
problem of restoring p[roper formatting and layout
when information is delivered to end users has always
been what has killed its widespread acceptance. 

My original post on this thread simply suggested that
a FrameMaker XML server (with Unicode capability and
elimination of other existing shortcomings) would
offer a much superior and simpler way to deliver
formatted XML instances to users, and retain the
highly desirable concept that authors are in the best
position to decide what the document should look like
when it is delivered to end users.
=============================================== 
You also wrote:
> I have never heard the word "successful" defined 
> by whether or not what was attempted turned out 
> to be easy or hard, or even cheap or expensive. 
> In many cases, "successful" is not a certain 
> term.
==============================================
"Successful" in a business sense usually means
offering the easiest, most intuitive way to satisfy
demanding requirements with high efficiency. By
efficiency, I mean that the product minimizes the
amount of time users must spend doing unnecessary or
complicated things which are unrelated to the main
task which the product is intended to facilitate. In
the case of software, success almost always goes to
the most flexible, adaptable product that provides all
the required features and options, and hides as much
as possible of the implementation of those features
and options "under the hood." Fundamentally, the
software ought not to force users to get bogged down
in implementation details imposed by the software.

By that standard, DSSLS, FOSIs, XSL and XML-FO are are
not successful. Not successful for many reasons, such
as the fact that the user has little or no say about
how the document he/she is writing will be formatted
when it's delivered to users. Not successful because,
in many, if not most cases, the formatting of the
document as it appears in the authoring software may
differ radically from the way it will appear to users.
Not successfuly because it disunites the tasks of
writing and formatting. Not successful because it
replaces the intuitiveness of modern desktop
publishing systems with non-intuitive reams of coded
formatting instructions that are unintelligible to all
but a chosen few--a chosen few who, in most cases are
entirely disconnected from, and care little about, the
process of writing good technical documentation.



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