Flexible & Modular Parsing/Drafting for Cicero templates

[jeromesimeon]

Is your feature request related to a problem? Please describe.

It is currently difficult to create custom text in clauses or contracts for specific types (e.g., for addresses, amounts, stock quotes).

Specific contracts / data may need specific rendering or text representation, but currently those have to be built into Cicero which limits a users's ability to specialize the text for their unique needs.

Describe the solution you'd like

It would be wonderful if users could easily specify special purpose parsing/drafting code for specific types.

[jeromesimeon]

The new parser work (in markdown-transform) includes a minimal kind of parsing table which could be a start in supporting more modular parsing/drafting.

Some notes from discussion with @dselman on the topic:

Parser Manager

• ParserManager maintains parser information + model info
• ParserManager allows to compile (and cache) parser spec into JavaScript for execution
• ParserManager is a bad name now cause it handles both parse and draft
• ParserManager should live above the raw transforms rather than the otherway around
• ParserManager is parameterized by a table (type+locale -> parseSpec+draftSpec)
• parseSpec+draftSpec can be a variety of things:
  • JavaScript parse/draft (for a locale)
  • grammar (for a locale) from which both parse and draft are derived
  • ciceromark (for a locale) from which both parse and draft are derived
• Add another layer (somewhere?) for resolving URLs to parseSpec+draftSpec
• Compiling the parser can be done for a given locale

Open questions

• when resolving a grammar to a parser, how to add dependent
• where should remote description for parsing happen? whose responsibility is it?
• how do we expose extension points to the API (and maybe CLI)?

[dselman]

Very nice.

I think I lean towards making the loading of remote grammars a separate concern, so that we don't have network access inside the ParserManager. E.g. we could create another class that takes a map of CTO FQN -> URL and resolves it to CTO FQN -> Grammar.

We can then decide how this gets exposed inside a Cicero archive. E.g. something like:

type-grammars.json inside the text directory.

[
   {
      "fqn" : "org.acme.Address",
      "locale" : "en-GB",
      "url" : "https://acme.org/templates/address.tem.md"
   },
   {
      "fqn" : "org.acme.Person",
      "locale" : "en",
      "grammar" : "{{salutation}} {{lastName}} {{firstName}}"
   }
]

Or sub-folders, if we wanted to make it easier to edit (no problems escaping quotes, for example):

/text/org.acme.Address/en-GB/ref.json (definition packaged outside the template, JSON contains the URL)
/text/org.acme.Person/en/grammar.tem.md (definition packaged inside the template)