Not off-topic: Wrong couple divorced after computer error by law firm Vardag's (Erik Nijenhuis)

[Erik Nijenhuis]

On Wed, 2024-04-24 at 18:01 -0700, William F Hammond wrote:
> Erik Nijenhuis writes:
> 
> > . . .
> > For some simple legal documents, I would use Markdown as input source.
> > I find XML way to technical for legal authors.  , , ,
> 
> In my view XML markup for documents is not more technical
> than LaTeX markup so long as one does not mix XML
> namespaces.  They are at the same level of technicality.
Always good to have an alternative, I guess ;)


> I would see the use of both LaTeX and an XML markup for
> documents as less technical (and probably better) than any
> deployment of JSON or YAML for document markup.  [ For
> example, look at pandoc's translation of Lamport's standard
> example sample2e.tex into JSON/AST. ]
JSON and YAML is client related user-input in this case.
The choice for YAML or JSON is so that the user-input simply can be queried by
an HTML form. The conversion between the two are trivial, also the integration
with LaTeX documents, if you take lua-placeholders into account.


> > Lastly, I use YAML for user-input (which client, which rate, etc.). To
> > give an idea, one YAML file results in the full compilation of a
> > proposal (typical letter class), an assignment agreement (typical legal
> > document class), and the underlying terms and conditions (also typical
> > legal document class).
> 
> 1.  I think this means that you are using YAML only as an
>     envelope for several LaTeX documents and not that you
>     wrote, for example, the source of your terms and
>     conditions in YAML.
> 
>     Is that correct?
Yes, the YAML file is the technical interface for a compilation request of three
documents in the case I described.


> 2.  Looking at meta information in the PDF that you posted I
>     see that "Xerdi" is listed as PDF creator.  How is Xerdi
>     involved?  Is YAML part of what Xerdi offers?
Xerdi is the name of my company, which aims to bring free software to business
cases. The whole ordeal started when I was ordering legal documents from a
lawyer.
He provided me docx files, which I then converted to LaTeX in my company's
branding.

He was really impressed by the quality output and even considered using LaTeX,
given the fact that I also could implement and deliver the client system
containing the HTML forms.

It was only me thinking LaTeX would be too hard to cope for this lawyer, so I
started working on Markdown support for the legal domain.

The idea of separating user-input from document drafting came from a major
insight after he told me a case where it definitely went wrong with some client
in his career. Namely:

Client asked lawyer what a privacy statement costs. (he already had a privacy
incident)
Costs were too high, client decided to write it himself.
Client couldn't write it himself after all and payed the lawyer for a privacy
statement.
Client edited the creation date in the MS Word file provided by the lawyer.
Client eventually payed for:
 1. not having the privacy statement in time
 2. paying the lawyer for the privacy statement
 3. a fine for fraudulent change in the document

While it is totally up to the client own responsibility, the lawyer nonetheless
gets some bad reputation out of this situation I would guess.

I also have some technical documentation of this lawyer client approach with
HTML, YAML and LaTeX/Markdown, within my latest product specification of Xerdi's
Documentation Project (XDP), where the lawyer is the "Author" and client is the
"End User" in the diagram:
	https://xerdi.com/static/public/xdp-product-specification.pdf
Note that it's still subject to change and may not forever be accessible.

Also, my article on lua-placeholders in TUG might give a good impression of the
YAML approach.
Location:
https://tug.org/TUGboat/production/45-1/tb139nijenhuis-placeholders.pdf


Kind regards, Erik Nijenhuis