|
Hi all,
I was going to send this as a private message to
Laurie as I had a recollection she had document automation as part of her DP
application, but I thought it might be of more general interest, and so I
jhave expanded it a little.
In the past I have used WP5.1 for DOS as a high
quality print engine for DP, exporting a secondary merge file from DP and
merging it with a WordPerfect primary file. It is a very powerful and flexible
process, however one of the issues with conventional merging is the problem of
merging relational data, ie multiple related tables. A simple invoice where
there are multiple items lines on the one invoice can be quite a challenge.
Fortunately there are ways to do with this WordPerfect using its merge/macro
language by creating loops to loop through the fields that make up the item
lines, but it is not for the fainthearted. But, alas, it is now pretty well
impossible to base a system on the merging of data with WordPerfect, dare I say
it, WordPerfect is dead or at least on its death bed.
Most people now use Microsoft Word, but merging
data with Word is not very satisfying. You either jump from simple merges which
do not have anywhere near the power of WordPerfect or else you take a leap and
use VBA or VB.NET and Automation (which is essentially programming the control
of one program from within another program). With Word Automation there are a
variety of ways of populating a document with data, eg searching for bookmarks
and replacing them with the variable data, inserting document properties and
using the results in fields, or even dynamically writing out the document. All
possible but very time consuming, therefore expensive, requiring good
programming skills, and basically putting most of the document creation into the
hands of experts. There are various 3rd party tools for assembling documents,
and mostly they are quite expensive, and not easy to use. Mostly these
solutions involve using Word at the client end, ie on the user's desktop. Server
side creation of documents in this fashion is not recommended as Word requires a
larger amount of user interaction, and cannot handle concurrent Automation
sessions, so is single user throughout the document creation process, which
makes it totally impractical for server side work.
From Word version 2003 onwards, Word has been able
to read and save its documents in an XML format. This has some great benefits,
especially since the documents can be read by other applications, and therefore
data can be extracted from it. Normally once data went into a Word document it
could not be easily extracted, but by attaching XML Schemas to the document you
can enforce various structures to the document, making each document's content
easily accessible to another application.
Another benefit which I have been looking into is
the creation of documents by using a Word documents using
XML. Although many documents are now programmitically created from
XML the major method employed is either using Word Automation, and/or using
WordprocessingML to
build documents from XML fragments.
Curiously, although tools are available, it seems
only a handful of people seem to be doing much work with using XSLT to create
Word documents. XSLT is the main method of transforming XML into HTML documents,
so I am surprised it has not had more traction. Since a Word document can be
saved in XML it can be converted to an XSLT template, which can be used to
"transform" XML data to create a "merged" document. The real
advantage of this over more conventional merging is that the data can be
relational, so taking the previous example of an invoice where one invoice
can have many line items XML makes this very easy. In fact extremely
complex data structures can easily be incorporated into the "merged" or "styled"
result document.
I have been using Microsoft Access and
also dabbled with SQL Server 2005 to create the XML document. You
really have a battle when using Access as Access does not understand XML
Namespaces which are a critical component of using the data in Word. SQL Server
allows you to do a little more, as it understands Namespaces. Neither owever
allow you to directly associate a style sheet (XSLT template) to the XML
data.
With Access you need to transform the original
output from Access into a new XML document which includes a Namespace for your
data, additionally you might need to do some very serious programming
work with Access as the inbuilt ExportXML is
very rudimentary. SQL Server removes this step so you can you can created
SQL
statements that create the XML
The way this is used in Word is that you open the
XML Data sheet and then browse for a Stylesheet (ie the Word template) and then
the document is "transformed" and you can view the document on screen. In
this scenario Word is the XSLT processor, but it need not be. In fact any XSLT
processor can be used, giving rise to immense flexibility.
Although DataPerfect doesn't itself understand XML,
because you can create whatever text output you want you can easily write
complex XML output. Since everything is in your control you can add one or more
Namespaces to the output, and if you like you can specify an XSLT
template.
If an XML document specifies a Word XSLT template
then Word will open the document and transform it automatically without the user
needing to browse for the template. This already makes the output from
DataPerfect easy to use than output from Access or SQL: Server.
If you are using a different XSLT processor, then
you can create the final Word document without even using Word, which means it
makes it easy for server side production of complex documents. Even though
the final result document is in XML format if you give it the the file
extension, .DOC then Word opens it, sees that it is XML and treats it like an
ordinary Wiord document. Similarly, if the file has a .DOT extension Word opens
it as though it were open a new template, which is handy since it will not get a
filename and the user can save it however they please.
DataPerfect then become a perfect accompaniment to
creating Word documents. It can be used in its normal desktop mode, or it can be
use in the web enabled mode, delivering completed Word document across the
Internet or organisations Intranet. You can even deply the final document
to users who only have the free Microsoft Word 2003 viewer.
Writing the XSLT template is the hard part, but
Microsoft has made that easier with a free download called the WordProcessingML
Transformation Inference Tool , which has very scant documentation but
which does a very good job. With simple XML documents even very basic users can
create long complex documents templates quite easily, but with more complex XML
documents or more complex formatting then some knowledge of XML , XSLT , XPath and Schemas will
be very helpful.
The documents themselves can be very rich. You can
use almost any Word feature in the document except perhaps embedding data from
other applications, unless you know those applications will be available. So for
instance if you used Excel to graph something, and embed the results in a
document it might be more prudent to use MSQuery and MSGraph to bind a graph to
a table in word. You can start the creation of a new template either by
starting a new document based on an XML sample, or you can take an existing
document and attach an XML Schema to it.
I hope this information is useful and perhaps can
give you some ideas to give new life to your DataPerfect applications.
By the way, I am about to try a complex
VoIP PBX routing application using XML from DP, Access or SQL Server. The
gist of the application is that customer service staff after creating an
incident with a client, will have that client's incoming phone calls routed to
the correct person dynamically. So instead of preprogrammed route being
established in the PBX, the information for the phone routing will
come dynamically based on the caller ID. In theory all that is required is
to pass the phone number in the query string of a URL, to a CGI program in front
of DataPerfect customer service application. eg http://www.mydpserver.com?phone=2159999999
and use the application to decide who should answer that call. Of course the
VoIP PBX software has got to support that type of interface.
Regards
Brian
|
