0

I would like to find or create a syntax to express business contracts programmatically, and I am looking for a robust, flexible, future-resistant way to do this.

A client should be able to add a negotiation points of varying types to the contract.

An example of a boolean negotiation point:

  • "There is a pre-payment penalty?" (yes/no)

While the above is certainly doable, it seems more difficult to describe the relationships between the negotiation points in an abstract way.

Some examples:

  • $600 is paid by "Client A" for inspection.
  • The above amount is paid by "Client B" if condition Y (information that should have been disclosed before the inspection was not disclosed).

Some other possible functionality:

  • Virtual fields are calculated based on the numeric values of other fields.

Notes:

It certainly seems like XML or possibly JSON-schema are possible candidates for describing the above. But I am open to other options.

http://en.wikipedia.org/wiki/List_of_XML_markup_languages

Many thanks,

closed as primarily opinion-based by Telastyn, user40980, user53019, gnat, jwenting Sep 26 '14 at 12:46

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • You mean a "business contract," right? – Robert Harvey Sep 23 '14 at 22:39
  • XML and JSON seem like horrible approaches since they don't actually do anything. Contracts need to enforce behavior. – Telastyn Sep 23 '14 at 22:58
  • If you're not afraid to mess with parsing and syntax trees, you could probably make a domain-specific language to represent what you need. That would be the most extensible way of going about it I would think. If that's what you're looking for, look for a programming language that has heavy support for macros and DSLs, such as a flavor of Lisp or Scheme – Jack Sep 23 '14 at 23:00
  • @RobertHarvey: Yes, I'm talking about "business contracts". – Nathan Lippi Sep 23 '14 at 23:57
  • 1
    @Nathan: I heavily recommend Racket if you wish to go this route. The language has a large toolchain of built in components for building advanced macro systems and entire languages. Common Lisp macros are purely symbol substitutions in nature, which have a few complications associated with them (look up hygienic macros vs. unhygienic macros). Not saying CL is a worse language, just that if you're looking to use a language primarily for its DSL capabilities than you're better off with Racket. – Jack Sep 24 '14 at 0:09
2

The most commonly accepted way is to use a Business Rules Engine of some sort.

Of course, if you're willing to roll your own BRE, and just need a reading on the markup language to use, I would imagine that XML is as good as any. It is hierarchical, has namespaces, and is unlikely to become obsolete any time soon. Since it's likely that we're not talking about gigabytes of markup here, the angle bracket tax is unlikely to be a real issue.

2

At the syntax level, either XML or JSON would do fine. But that's the easy bit. The challenge is defining what can go in the rules. I would adopt a standard object modelling approach: what are the entities you need to represent, and what are their attributes and relationships? When you know that, encoding it in XML is easy.

  • Agreed that the challenge is what can go into the rules :). Have been doing a little of that so far. – Nathan Lippi Sep 24 '14 at 1:37
2

The biggest problem is the huge set of assumptions that you so easily skip.

Just take your example: "$600 is paid by Client A for inspection"

  • USD or other dollar?
  • Paid when?
  • To whom?
  • What counts as an inspection?
  • Is this a mandatory payment, or only incurred if A opts to do the inspection?
  • Are multiple inspections allowed, If so, is this per inspection?

Your DSL will need to deal with all this complexity. For contracts in English, lawyers have already developed ways to resolve such issues, and even prevent them by reviewing draft contracts.

  • 1
    Moreover, they have a defined environment in which conflicts or ambiguities can be resolved, and that serves to enforce the contracts: the court system. – Jonathan Eunice Sep 25 '14 at 14:50
  • @JonathanEunice: Good point. In one of my comments I mentioned that this DSL should be able to be translated into English and a UI. – Nathan Lippi Sep 25 '14 at 15:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.