Re: Database Publishing Suggestions

[David Evans <devans@xxxxxxxx>]

Dan, Dan, Dan,

You are not a priority. In the past 5 days I have been in Denver, Santa
Clara, San Jose, Chicago -- closing large business opportunities -- clients
that have real database publishing needs. And all the while, FML phones
continue to ring for want of our abilities. 

I did notice the absence of any reference to our dynamic capabilities,
graphic resizing etc., etc. You only respond to certain facts that maybe
might cloud the issue.  You have already shown your colors -- you don't
need to explore new technology -- you know it all. How can anybody
demonstrate anything new to you?

But quickly let me ask you:

What is MIF, if not a tagged file format.  Your PDF document "Database
Publishing with FrameMaker & Unimerge" suggest MIF.  In your terms what is
MIF, the inquirer really wants to know?

Is that sample which you shared (99% published mostly using "background
information") what you call high-end?  I felt that you would offer some
market experience, real projects that you have completed.  Again, I ask
you, "where do you want to go today?"  In a recent post you talk of
Luckman, from scratch to finish how long to implement?  How fast to run
those pages? I find it humorous that you have to go back each year to
re-publish it for them.  With PatternStream, once implemented, they merely
hit the button anytime they want to republish it -- they don't need Danny
boy -- pretty scary, huh!

Holding out the speed argument -- did you include the whole picture --
implementing the queries, the data extract, the cumbersome file management
stuff, through to MIF and then final file import?  Your story is partial,
you didn't included what MIS must do for you -- you must go back and forth
with MIS, others do the work for you, no wonder you think it is so fast --
see they don't need to do that with PatternStream.  So please, tell the a
whole story -- you continue to leave out parts.  Importing ASCII text is
only a partial story -- pretty impressive speeds for ASCII import, I'm
impressed! 

Please show me a high-end application, something like a catalog with
colorful pictures.  I offer to you my examples (and any one else
interested).  Tell the group how you would implement the same and how long
it would take.  Can you share any books, catalogs, or major
implementations, something with complexity, 100% variable?  

In reference to your "UNDISPUTED CONCLUSION", the only thing that I can
conclude is that you haven't yet demonstrated a "real" application nor
implementation.  Please review the books and catalogs in our examples.
Also note the table straddles, the complex header formats, all 100%
variable if need be.  Also, placement of graphics -- many resized
on-the-fly?  Got anything interesting to share?  

As stated in my last email -- I won't play your game!  You don't include
the facts and you give partial stories.
One minute it isn't tagged data the next minute I read it uses MIF, common
'fes-up, tell us the whole story. 

How long to implement the Columbia Books CPA example?  And how about the
Motor example, you know the one with the varying straddles that are shaded
differently too.  And most importantly, can you even do these?   These are
the types of projects that require PatternStream and why we are called in
to share our technology.





At 11:40 AM 2/8/99 -0700, Dan Emory wrote:
>My original message that kicked off the debate between myself and David
>Evans of Finite Matters about the comparative advantages of UniMerge and
>PatternStream was as follows:
>*********************************************************
>The answer is UniMerge, by Refined Reports. I've been using it for about 4
>years to produce all sorts of ready-to-print FrameMaker documents from
>database extracts. At $695 for Windows Platforms ($995 for Unix), it does
>everything PatternStream does faster and better, at a fraction of the
>PatternStream license cost. If anyone is interested, I'll send you a 6-page
>PDF file describing database publishing with FrameMaker and UniMerge.
>***********************************************************
>Not having received any further rebuttals in the past 5 days from Mr. Evans,
>I conclude that the following facts are not in dispute:
> 
>1. Mr. Evans originally took offense to my claim that UniMerge was faster
>than PatternStream, declaring:
>"To be clear, PatternStream will out perform any meta-tagged based system --
>bar none."
>He also stated that he preferred to measure speed by the number of pages per
>minute produced by the competing products. He cited PatternStream's
>performance to be between 5 and 72 pages per minute. I responded by sending
>him an example of a high-end UniMerge database publishing application in
>which I achieved a production rate of 1000 pages per minute on a 266 MHz
>platform. I've also achieved production rates of up to 5000 records per
>minute on the same platform.
>UNDISPUTED CONCLUSION: My original claim that UniMerge was faster than
>PatternStream has been substantiated by Evan's own performance figures.
>
>2. Mr. Evans seemed to think that UniMerge is a "meta-tagged based system"
>It is not. It can use nearly any commonly used format for database output,
>and does not require any "meta-tagging" of the database output.
>UNDISPUTED CONCLUSION: UniMerge is not a meta-tagged based system. The main
>difference between the two products is that UniMerge uses a powerful command
>language (the commands are embedded in the WYSIWYG FrameMaker report
>template) instead of a GUI. It doesn't take a rocket scientist to know that
>applications that don't have GUIs run much faster than those that do. Also,
>it's much easier to add new features, (e.g., new commands) to a non-GUI
>application. On at least 4 or 5 occasions, I've made suggestions to Refined
>Reports for improving UniMerge. In each case, I got a Beta version back for
>testing in less than 4 weeks. 
>
>3. Mr. Evans disputed my statement that there were many cases where a live
>database connection for database publishing was out of the question,
>declaring that:
>
>"I can't think of a case that it is absolutely out of the question"
>
>In response, I re-stated that, from my experience, it is more commonly the
>case that a live connection is not available, and provided numerous
>real-world reasons why that constraint often exists.
>UNDISPUTED CONCLUSION: Although UniMerge and PatternStream both have a live
>connection capability, it is more often the case that, not only is such a
>connection unavailable, but even if it were, it is often more efficient to
>perform the database publishing activity in a batch processing mode, as
>UniMerge can do. There remains a question of whether PatternStream presently
>has a true off-line batch processing capability.
>
>4. PatternStream's GUI might, in some cases, reduce development time a bit,
>but UniMerge's far more flexible approach, combined with the power of its
>command language, has distinct advantages for solving problems that might be
>intractable with a GUI.
>
>5. PatternStream requires far more computer resources than UniMerge, as
>proven by the system requirements specified on the Finite Matters web site.
>I've used UniMerge with my 266 MHZ platform (32 MB memory and a 2.1 GB hard
>drive) for numerous high-end database publishing projects, some having as
>many as 50,000 pages.
>
>6. I continue to maintain that UniMerge can do 95% of what PatternStream can
>do, and do it much faster with fewer computer resources. But I also contend
>that the remaining 5% of applications which PatternStream could crack is
>probably offset by the 5-15 percent of applications crackable with UniMerge
>which could not be cracked with PatternStream. Although I do not know
>PatternStreams's license cost (that seems to be a closely-held secret), I do
>know that UniMerge, at the retail price of $695 for Windows ($995 for Unix),
>is at least 10 to 20 times less costly than a PatternStream license. Macs
>running Real PC can use the Windows version. 
>     ____________________
>     | Nullius in Verba |
>     ********************
>Dan Emory, Dan Emory & Associates
>FrameMaker/FrameMaker+SGML Document Design & Database Publishing
>Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
>10044 Adams Ave. #208, Huntington Beach, CA 92646
>
>
>** To unsubscribe, send a message to majordomo@omsys.com **
>** with "unsubscribe framers" (no quotes) in the body.   **
>

"publish in minutes...Not days."

Finite Matters Ltd.
David V. Evans
703-807-2108 Voice
888-766-1087 Pager
mailto:devans@cmyk.com

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