Re: Database Publishing Suggestions

[Dan Emory <danemory@xxxxxxxxxxxx>]

The original of this message to David Evans of Finite Matters had an
attached 200 KB PDF file containing five examples of database publishing
applications I've implemented with UniMerge. Anyone else who's interested
can request this file (EXAMPLES.PDF) from me. 

At 10:05 PM 2/8/99 -0500, David Evans wrote:
>-----------------Snip
>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?
##############################################################3
I tried to set you straight on this in an earlier post today. Here's what I
said:

But UniMerge doesn't create a MIF file in the conventional meta-tagging
approach you've previously described. It creates the merged output file from
the FrameMaker report template (created as an ordinary FrameMaker file and
saved in MIF format). UniMerge creates MIF by cloning the MIF statements
that wrap each field (or set of concatenated fields) in the report template,
replacing the field name(s) wrapped in the MIF with their values at merge
time. In this way, UniMerge exactly replicates the MIF statements from the
report template MIF in the merged output. From the standpoint of the end
user, the distinction between producing a FrameMaker file in MIF rather than
native binary format is meaningless. Both open in FrameMaker. The advantage
of using MIF the way UniMerge does is that the merged output can be produced
much faster.
########################################################################
>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.
##################################################################
No, as I also explained in my earlier post today:

I gave you that questionnaire sample to show UniMerge's upper-end
performance capability of 1000 page per minute (You're the one who called
for the pages per minute criterion, I simply proved with that sample that
UniMerge is faster no matter which criterion you choose).
###############################################################
>Again, I ask
>you, "where do you want to go today?" 
#######################################################
Hmmm. Is that slogan original? Seems to me I've heard it somewhere before.
###############################################################
>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!
###########################################################
Wrong again. They could publish the thing themselves from the application
package I produced for them, but they're just not interested, because they
don't have in-house staff capable of doing it, and see no reason to hire and
train people for that once-a year task (In this case that's certainly the
best way to improve ROI). The book includes three large generated indexes
produced by FrameMaker from markers embedded in the output by UniMerge.
Furthermore, they're under contract to Barnes & Noble to produce a book with
at least 10,000 websites in exactly 1216 pages. It takes considerable
post-UniMerge finagling to bring in the page count at that number. I know
how to do it. They don't. Am I "scared" that Luckman might replace me with
PatternStream? Not a bit. 
###########################################################
>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.
############################################################
What utter nonsense! Are you trying to tell me that PatternStream is better
at implementing queries than a competent MIS group that owns the database?
As I stated in an earlier post, I would guess that the typical MIS group
with a half-way decent query implementation toolset would regard
PatternStream as a tinkertoy.

And do I believe that a typical MIS group can implement complex queries more
cost-effectively and reliably than a non-MIS group trying to do it with
something like PatternStream? You bet I do.
##################################################################
>---------------------Snip
>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?
################################################################
I saw nothing in your sample set that UniMerge isn't capapable of doing.
Nor did I see any instances of wide variations in table structures. A
FrameMaker report template for UniMerge can tell UniMerge to examine the
records so as to determine which of a finite number of table variations
should be used. Similarly, if there are a finite number of graphic sizes,
and if the graphic size is indicated in some manner in the record data,
sizing the graphics can also be handled by UniMerge (this is shown in the
auction catalog example I'm sending you).
###################################################################
Now, let me describe a few capabilities of UniMerge. I'd like you to tell me
if each of those capabilities are available in the existing version of
PatternStream that is now being sold to your customers:

1. Determine and report the character count in a string field.

2. Inspect a string field for a specified sub-string, and report not only
whether it was found, but also, if found, the starting character position of
the substring.

3. Extract a substring from a string field, permitting both the substring
and the entire string to be used at different places within the record
structure.

NOTE: The above three capabilities can, for instance, be used together to
perform what amounts to gene splicing on a string, in which the string is
split into two or more substrings, and then the substrings are put back
together with something removed, and/or with something new inserted between
two substrings.
 
4. Test for anomalous or defective records, and report them in a logfile
produced at the end of the merge operation. The log file can uniquely
identify each such record, and can also describe the nature of each
exception or anomaly. The logfile can also report the exact number of
records that were processed, and the time it took to process them.

5. Set template-defined report variables, semi-persistently if needed, based
on the evaluation of the value(s) in one or more record fields. For example:

        IF (field1 = x) OR (field2 = y)
                SET varxy "1"
        ELSE
                SET varxy "0"
        END

These are not FrameMaker variables, they are UniMerge report variables that
can be used like actual record fields (e.g., they can appear in the output,
or they can be used in some other manner to control variations in record
structuring and formatting). By semi-persistent, I mean that only certain
records might change the value in such variables, and those values persist
so that they can be used while processing subsequent records. In other
cases, such variables may be set for each record that is processed. Report
variables can, for instance, be used to store the results of the operations
described in items 1, 2, and 3 above, and in the note below item 3.

6. Insert into the merged output fragments (e.g., a paragraph, or a whole
page), that may include not only formatted text but also tables and
graphics. A library of such fragments, each of which has a unique identifier
tag, can be stored in an external FrameMaker file. The particular
fragment(s) selected for inclusion at some point in the merged output may be
determined by the value(s) in record fields or report variables. These
fragments may also have embedded in them field or report variable names,
which are replaced by their values at merge time.

I've had applications where each database record produced an entire booklet
(e.g., a customized employee benefit booklet) made up of fragments selected
by the values in the fields of the record. The values of some of these
record fields may also be inserted into the fragments themselves at merge
time. A single enumerated field in such a record could, for instance, be
used to select one fragment out of many possible ones for inclusion at a
particular point in the merged output.

7. Derived fields which are computed from the values of other fields or
variables, that can be included in the merged output. Such derived fields
can have arithmetic operators (add, subtract, multiply, and divide), as well
as aggregate functions (sum, average, minimum, maximum, and first) for
repeating groups of sub-records.

8. A look-ahead/lookback capability that allows field or variable values in
the current record to be compared with field values in the next or previous
record.

9. Execute an operating system command at some point in the merging process.

I have found that one or more of these UniMerge capabilities often makes the
difference between success and failure in implementing difficult applications.
####################################################################
In an earlier post to me on this subject, you stated that PatternStream
could operate without a live connection to the database. I'd like you to
describe exactly how the existing version of PatternStream would actually
work in the case where a live connection to the database is undesirable,
infeasible or impossible.

Best Regards
     ____________________
     | 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.   **