On 6/14/06, Mikko Silvennoinen <[EMAIL PROTECTED]> wrote:
To the solution of the pleadingpaper issue: I think it would be ok to have multiple templates, and a macro/script to help and guide of choosing the rigth template for each case. I finally went thru your work plan outline for Ooo-pleadingpaper project. I would leave most of the stuff to the enduser.
The sad fact is that creating a template of this complexity is a task for which most end users lack either the necessary skills or patience, or both, let alone what is needed to extend the basic template for automated document assembly purposes. So a well-documented basic pleading template with step-by-step instructions for its recreation and use would seem to be fundamental to spreading the relevant knowledge and for code warriors to use the requirements for development of automated assembly solutions. End users can still hack the thing or roll their own. There is a related problem in that OOo Writer templates are not self-documenting like WordPerfect templates are using the WP Reveal Codes feature. You can get at the same kinds of information by looking at the XML, but few people are going to go to the trouble of learning OpenDocument XML markup so they can determine how a template was created. So the law office tradition of not bothering to document how WordPerfect files were created really does not extend well to OOo templates. E.g., with the pleading templates downloadable from OOoExtras, I had to scour Writer for features that might have been used and experimented with them. So I believe a basic pleading template that is fully documented would be an important resource for OOo end users and for developers. [more] To make a system that covers every jurisdiction and every country sounds
like a mega project that will never be ready.
I apologize for not being more clear on that issue. I'm not proposing that no templates be released before there is one for every jurisdiction in the world that uses a pleading template. Indeed, I believe individual templates should be released as soon as they are useful. But I am proposing that we all focus first on developing very specific requirements for a single reference version. Otherwise, we will all be rowing in different directions. Once we have a single reference version, then we can turn our combined experience on developing a variant that can serve as a building block for still other variants. E.g., if we get one template perfected for a basic U.S.-style template, then we can work from that to develop a basic template for countries that use different standards such as paper size, measurement units, etc., that you mention below. Another big advantage of creating a very specifically-defined reference version is that doing so will help people realize and tell us why the requirements we are using do not work for Jurisdiction X. We can then look at whether the flexibility to accommodate Jurisdiction X can be built into the basic template or whether a variant will be needed. [more] This will be difficult on such a detailed goals that you have, because:
we have different mesuring units: you have inches I have cm, we have different paper sizes: you ? I have A4, in other countries -different languages, legislation, practices, character sets (everybody!: from now on UTF-8) ...
But assume that the basic techniques we develop can be used to create pleading templates in other countries. E.g., if a table in a frame in a header produces a good solution not only in ODT format but also when exported to PDF and HTML, is not the task of creating a standard template for use in Finland easier if all that is needed is to specify differences from the root reference version? I.e., most steps will remain the same to create the basic Finnish template and its documentation and only the necessary deviations from the reference template and documentation need be specified. And if someone wants to create a customized template from either the root reference version or the Finnish basic template, e.g., adding database connections to fill fields in the body text area, is it not preferable that such customizations be based on a standardized template? If we can develop standardized templates and build a database specifying their differences, then it becomes far easier for coders to design dialogs that can make it far easier for people to configure custom templates. E.g., a simple scripted dialog could be created for addition of firm contact information in the desired location and setting the font, font size, and font weight for that information. [more] But if we play with the thougth, you first would have to build a
database of all requirements, in such a way, that the script asks the jurisdiction and all other relevant info and reads the requirements from the database and according to that makes a pleadingpaper (template).
No, I think only the requirements for the basic template and its jurisdictional variants. Even for those, one at a time. E.g., a single full-screen dialog could easily handle things like setting paper size, units of measurement, character sets, language, font details, and all the other requirements. Where we have already developed variants for a given jurisdiction, then only the selection of the jurisdiction would be necessary other than for customizations like the firm contact information and its formatting and selection of its placement. This is not to say that there is any great technical barrier to retrieving necessary settings from an internet-based database. But it should not be difficult to go far beyond the limited WordPerfect Pleading.wcm macro. I don't think creating lots of different templates is where we should go; instead, I'd like to see us moving toward development of an application for creating pleading templates that can function as an OOo extension and also as a stand-alone tool that can be used in conjunction with other programs that support OpenDocument. After all, this is a software stack built on an open file format standard, not on any particular application that supports that standard. IMHO, an application for creating pleading templates should be a scriptable modular app that can be used anywhere OpenDocument can be used. [more] But if you have that kind of database, you don't have to limit the
output to a template. You could connect to other databases with info about legislation, prejudicates, and the data saved from your (and others in your office) previous cases. Then you could put the script (rather script calling other scripts) help also on the contents of the pleadingpaper (or any other legal document).
Exactly. But you have to pour the foundation before you frame the house. [more] I would settle to make some versions of pleadingpaper template, and
teach everybody, at least the law students and secretaries, how to edit those templates. Your outline for project plan could serve as a base for knowing which variables can change in different versions of templates.
I wouldn't be working on this project if it had no potential for its work products to proliferate. And yes, what I would like to see us shoot for initially is a complete specification that documents every keystroke necessary to create the basic template, i.e., a recordable macro. If we have that, then we have what we need to create the OOo pleading template wizard. And as the wizard is refined to accommodate needed variants, we get the information needed to write the stand-alone app that can also be used as an OOo extension, the app that creates template files from scratch or simply goes ahead and processes the scripts needed to generate ODTs rather than OTTs, then passes the information to the work flow script that automatically assembles a customized but largely boilerplate document ready for final editing and printing/conversion to PDF. I think we have the same goal; it's just how we get there. I think we can jump-start automated document assembly in law offices by building a solid foundation of detailed requirements for a basic pleading document. But I see a building block approach to getting there. [more] I have used that database approach before, but I think it can only work
in one jurisdiction and in a narrow field of law. With a lot of similar cases you could have secretaries do the most of work after teaching them to use the templates/script/database system. The script/wizards took them thru to delivering rigth kind of documents. But I had to concentrate to keep the system valid by being absolutely sure, it contained all up to date information of legislation and prejudicats etc.. and the rigth rules in the scripts to be able to always come to the rigth conclusion.
That is one of the big reasons I'd like to see Round 1 develop a basic template that is free of content. To me, deciding what databases to connect to a template in what locations is outside what I think the scope of the project should be. I see the project as designing a bucket as opposed to designing a bucket and filling it too. [more] But to pleadingpaper: the fastest way to results would be to make a
lookalike file of a perfect pleading paper and put sticky notes where you want to have things noted that are functions that the lookalike don't explain just by looking. Remember to put sticky notes of what jurisdiction it is intended to etc...
Part of that is addressed by the file naming conventions I suggested. < http://evc-cit.info/pleadingpaper/#S4.2.1.>. But those are also reasons why I think we need absolutely stunning documentation of the basic template that can be distributed with documentation for the parts of a variant template that are different. We could probably even come up with an automated system that can merge documentation for variants into the proper sections of the main documentation file. E.g., the main documentation could be adapted for the Finnish version by a series of paragraphs properly located that say something like, "For use of the Finnish PleadingFinland-1.0.ott template, use the following metric measurements rather than inches for the following values. [Table] [more] I still have an issue of the licensing requirements that Sun wants us to
sign. So it is possible, that I don't upload anything to this web-site, but let all download it along with my license from my new website. (It's still under construction for some time.)
What is the license? I had assumed LGPL for the software and PPL for the documentation. Did I miss one? It would be helpful if someone who is familiar with internationalization and localization of software might provide a link to or make a list of requirement topics missing from the outline that need to be added for internationalization and localization purposes. E.g., character set, language, etc. Wikipedia does not have the kind of list needed for the outline. <http://en.wikipedia.org/wiki/Internationalization>. The existing requirements in the draft outline are in section 4.2. < http://evc-cit.info/pleadingpaper/>. At this point I think it is more important to get all of the necessary requirements topics into the outline than to draft particular language detailing them. Also, does anyone know of any documentation for OOo development that describes its internationalization and localization features? Mikko, just to make sure I didn't miss something, do you propose any changes to the outline other than dealing with internalization and localization issues? Best regards, -- Marbux
