Document Assembly Dialogue; Roy Lazris’s Reply To Scott Curnutte

Please note that Roy does not argue with Scott. He is not that kind of guy. Instead, he addresses Scott’s observations the document assembly is just too complicated and expensive, and tells what he is doing to correct the problem.

Roy’s letter:

From: Pathagoras [mailto:info@pathagoras.com]
Sent: Saturday, January 29, 2011 8:38 AM
To: Burton Hunter
Subject: RE: Pathagoras

Burt,

FWIW, let me address one small portion of Scott’s comment, quoted below:
2) all use the same proprietary document-assembly program and commit to continue doing so for the foreseeable future; or 3) do our best to coordinate clauses so that when someone realizes that there is a huge market for XML editors with consumer-friendly features we can move more quickly to implement “pick, plug, print” (you can steal my phrase if you like it, but you have to footnote me).

No argument re: the ‘big picture’ Scott paints, but here is where at least Pathagoras can begin to come into the community.

Let’s start with two the ‘really big deal’ concepts that Pathagoras operates within. ‘Plain text’ and ‘faciality’.

PLAIN TEXT: Plain text promotes universality. (That’s what rich text was, maybe still is. That’s what XML purports to do as well, and in its world, it does succeed. But comparing Pathagoras with XML is apples and whales.)

Pathagoras uses plain text [variables] and plain text {optional clauses}. That means that documents that are created by anyone (you, me, Matthew/Bender, WestLaw) using square brackets to denote variables and curly braces to denote optional text, are potentially universal documents. (Forget automatic paragraph numbering and other styles that are the bane of universality.) If there were a WordPerfect version (I’m still thinking about it, but just don’t have the time), or Open Office or Lotus coding that could read plain text bracketed variables and present them onto a screen and then invoke that program’s search and replace routine to make the substitutions, then we have ‘lift off.’ Documents can be shared. No proprietary program will be required.

In fact, as the last few sentences above suggest, even now a ‘proprietary limitation’ is not even true. Anyone can create documents with [plain text variables] on any platform, and give/sell/share them with anyone. And anyone can write code to read them. (Of course, Pathagoras does much more than just replace [variables]. I would continue to market Pathagoras for those proprietary features. But, to the extent that others — including you, Burt, or Scott — publish documents that meet this ‘plain text [variables]’ model and standard, everybody’s universe of useful and automated documents is tremendously enhanced, Pathagoras installed or not. And there is at least one other program that reads and processes [bracketed variables]. It’s called “DataPrompter.”)

Of course, most programs today cannot detect [bracketed variables] with the intent of doing anything with them. That’s because those programs are trying to do too many other things with that text, many of those things quite worthless, and require much more than ‘plain text’ to do what they want to accomplish). To the extent, however, that a ‘simplicity revolution’ takes place, and plain text variables become a norm, then we begin to meet at least one of Scott’s requirements.

Speaking of plain text, the Instant Database record that Pathagoras saves out after the form is completed is just a csv file (comma separated value). That is another universally recognized type file. It too is saved all in plain text.

Of course, XML theoretically operates on the same kind of ‘plain text’ platform, but it is just too ‘behind the scenes’. The file structure of an .xml file is plain text. However, no one can read an XML document and make any sense of it. (In the same way that few people can open the source code for a web page and discern what it means. HTML is universal, it’s plain text, but it’s not what people can use. Despite the fact that HTML code has been around forever in its plain text glory, and despite the fact that there are any number of people-friendly programs that will help you to design a workable website, for the most part web pages and HTML code is still written by experts. Document are written by lay people like you and me.)

FACIALITY:
That is probably not even a word, but what I mean by it is that a typically user can see on the face of the document what the document is supposed to do. A [variable] is supposed to be replaced with a value. {Optional blocks are supposed to be kept if the answer is “Yes” or deleted if the answer is “no”.} The end user has to see within the 4 corners of the document what is supposed to happen. A Word2007+ document saved out as an .docx (using XML structure) is definitely not ‘facial’, at least as far as the XML coding goes.

I continue to force myself to keep ‘plain text’ and ‘facial’ in mind as I write new code and functionality into Pathagoras. It would definitely be a lot easier for me to do things using MS more powerful hidden fields, database links and the like as the big guys against whom I compete are doing. But my target market is really not theirs. Their target audience are the firms with IT staff. My target audience are the rest of the firms without such staff. That target audience will always be there.

When that day does come as described in Scott’s #3 above, I’ll be ready, not with XML, but plain text documents.

The fantastic ‘CaseMap’ features of document management and case control will never be a Pathagoras function. But when it comes to creating simple too complex documents, and despite all of its ‘low tech’ underpinnings, I am confident that Pathagoras is on the right track.

–Roy
—
Roy Lasris
Innovative Software Products of Virginia
www.pathagoras.com
info@pathagoras.com
1-866-PATHAGOras (1-866-728-4246) (tollfree)
(757) 874-7300 (fax)
(757) 877-2244 (Virginia, USA -day)
(757) 898-7374 (Virginia, USA -eve)

This post was written by Burton Hunter