There are several benefits for using XML over mail merge macros, especially in workgroup settings:
With most mail merge setups, there is some embedded VBA code in each Word template or in a general template, macros must be enabled, and if you want to reduce deployment issues and make it look professional you really need a digital signature certificate for your VBA code. There is either a multiple-step process or a fragile automatic setup that may break fairly easily. Managing the export file becomes an issue, or ODBC has to be used to avoid an export file. For infrequently used reports that can be generated by a trained person, this is OK, but for a work group the support effort seems much higher than it "should" be, both for the initial deployment installation and for general ongoing support.
With XML there are no Word Templates that have to be visible on the network on mounted servers or locally. There is no need to enable Macros. There is no need to setup an ODBC connection or worry about where the export file is located in order to then invoke the import, and there is no need for a digital certificate. There is no left-over export file that should be deleted or that may be confused in a subsequent export, and no local Word template file that has to be kept in sync with other users. New Stylesheets may be hosted on an http server and updated instantly for an entire work group without changing a line of code, and the result of the export function is not an export file but rather a word processing document.
For documents that fit the EZxslt model, an end-user may create updated stylesheets using the same export data without requiring any change in Scripting. All they do is update their Word Stylesheet Template and drag & drop. To install, they put it on the http server that is used. Very simple.
Unless someone has access to the web server to post an updated form, they can't modify the XSLT template and therefore the core template code remains consistent.
With Mail Merge, I've found typically only one or two people in a work group will bother to learn how to use the setup, and it is only used for infrequent, if important, tasks. For example, I've never been able to convince a client to set up their standard ad-hoc letters and memos to merge from FMP unless they also want to store the documents in FMP in which case Word is not used at all, and they put up with the funcky page break and other issues.
With XML, it is now possible, and clients seem interested in, using FMP as their work group rolodex, and quickly generating various new Word documents directly with simple information such as name & address pre-populated. This is a real time-saver and much simpler in many cases than opening a Word template, going to FMP, finding the record, copying the name/addres, and then pasting into Word.
There are nearly no environmental issues that get in the way. No macros or vba coding. No pathing issues to resolve. I can set up many more documents more quickly using XML/XSLT than using Mail Merge. In fact, now I'm looking at setting up many documents at once rather than just one or two.
You don't need MS Word to consume the results of a FMP->RTF conversion. If you choose to deploy Star Office or any other RTF-aware word or text processor, the RTF generated via XSLT should be openable. RTF Reader, TextEdit and other programs will work.
|Copyright 2002 Chaparral Software & Consulting Services, Inc.|
EZxslt is a trademark of Chaparral Software & Consulting Services, Inc.
Filemaker Pro 6.0, FileMaker Server, FileMaker Developer, FileMaker Unlimited are trademarks of FileMaker, Inc.
Microsoft Word is a trademark of the Microsoft Corporation.