Tactical Agreements

We want to be acceptable to IT professionals. They really like universal database concepts. Everything should be accessible with a TABLE.COLUMN.ROW type of reference. This means that those who use us in that way may be giving up much of the power of APL. Or, maybe we can be creative in the use of executable expressions and in our ability to move data and redefine formats between various environments.

The ultimate expression of our desire to make our software fit with "enterprise databases" will be to convert to a relational database the manner in which all of our inputs and outputs are stored.

• Our scripting language will be HTML with the exception that we may need to extend the list of tags & containers.
• XML is simply an extension of HTML.
• HTML does not provide for fields & records, XML does, so maybe XML should be our scripting language.
• XML will not be our scripting language. It will be one of the formats for which our scripting language will have a translator.
• The following is the order of priority for which we will implement our alternative interfaces.
  1. Excel (because it is the fastest track to cash flow).
  2. XML.
  3. Eric's objects (because GUI is details, details, details).

There is inconsistency in how we are discussing XML in the above statements. Please clarify. We did say XML is too verbose to be our scripting language, and that's consistent with the fact that I write HTML with APL functions rather than writing HTML myself. But I want us to see these things clearly, with, of course, the provision that we might later see things differently.

We have a strong desire to avoid a rigid user interface for ProCash & Landev. I've always imagined that GUI forms would be formed on the fly by sensing what data is present and shaping the presentation to the user appropriately. This will only be feasible in the Eric's Objects environment, I believe. For this reason, I will consistently be itchy to get to that 3rd priority in our implementation schedule (though top priority must be getting to cash flow ASAP). I'm hoping that Eric's Objects are so clever that GUI won't be "details, details, details".

There is risk that working far apart we will fail to hold to the same vision and plan. This page of our business plan is intended to help us avoid that. Later this might be removed from the business plan. I'll soon start developing a sub-business plan for our first niche market. Maybe it is a "business plan" all by itself and will ultimately be removed from our "enterprise" business plan.