Hi Tony,
But I have to say that having open formats based on standards of sorts is a
better way to have documents. XML documents are far easier to work with and
mean that data is not locked up in a proprietary format... WP for DOS was
great, and I am sure had it survived its abysmal transition to Windows, that it
probably would have gone down the XML route and would have done it far better
than Microsoft. Microsoft rarely has depth in its products, only what marketing
understand they can readily sell makes it in...
I would like to see in the information about production of RTF documents.
The main benefit of XML over RTF is that you would not have to create the
entire document inside DP, which is quite limiting. When you use external
stylesheets, it means that the DP XML output is incredibly simple... I should
post an example...
Regards
Brian
----- Original Message -----
From: Tony Perez
To: 'Dataperfect Users Discussion Group'
Sent: Wednesday, December 05, 2007 5:24 AM
Subject: RE: [Dataperf] Document automation with DataPerfect
Hello Brian ... quite a dissertation. :) Thanks for sharing.
FWIW, Bruce Conrad and Thom Boyer taught me how to produce .rtf documents
through DP which I used regularly between 2001-04 in sending trip proposals,
confirmations and invoices as Word documents. If you or anyone else in the
group want to hear more about this, I'll dig out my notes and samples.
It is really a shame to see WordPerfect "drift into the sunset". There's no
question about it being a far superior wordprocessor than Word with all of
those nifty tools such as macros and reveal codes. If someone has Bill Gates'
ear, they should convince him to buy it and incorporate it into the MS product
line. It will far improve their wordprocessor.
All the best,
Tony
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian Hancock
Sent: Monday, December 03, 2007 7:01 PM
To: Dataperfect Users Discussion Group
Subject: [Dataperf] Document automation with DataPerfect
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
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian Hancock
Sent: Monday, December 03, 2007 7:01 PM
To: Dataperfect Users Discussion Group
Subject: [Dataperf] Document automation with DataPerfect
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
------------------------------------------------------------------------------
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
