Hacker News Reader

Comment by jzwinck | Hacker News Reader

The problem with legal markup is the same as with FIX, the financial data protocol (which is widely used).

Lawyers (finance people) will never stop innovating (increasing complexity), and they will not be one moment delayed by a protocol which falls short of their aspirations for sophistication (bamboozling). Therefore, the only adoptable protocols are mere transports. They might rigidly specify some commonly used things like property titles (stock orders) but foreseeing unusual or unknown requirements, such protocols will include custom extension features (user defined fields).

The end result is a protocol which is sort of useful but still does not suffice for the development of generic tooling. An example from FIX is the field which tells whether an order added or removed liquidity. The standard didn't have such a field, so now every exchange has its own different one.

View on HN

I don't really see that as a problem, that's how all popular protocols evolve.

If all exchanges have invented a liquidity-field, then there's a good chance the next version of FIX will standardize it, no?

Imho the legal system is very much ripe for digitalization. Both on the low-end (where it pretty much consists of overhead), and even more so on the high-end, where the complexity of legal contracts between companies or states has long exceeded what any team of lawyers (much less a mere mortal) can comprehend.

The next version of FIX can try, but everyone stopped upgrading FIX versions years ago. Also, once you standardize the liquidity field, you need to think about its values. These expand continuously...it used to be two or three values, now some systems use a dozen or more.

Basically, if you want a protocol for legal documents, you may as well use an existing one, such as PDF, XLS, TeX, etc. Trying to embed more domain knowledge in the protocol will never work at a highly generalized level. It would be like asking HTTP to standardize e-commerce.

Well, let's not forget we're talking about lawyers here, who already work with a versioned single source of truth (The Law).

All I'm asking is that we upgrade their tooling and process.

Your outlook for the abstraction potential seems overly pessimistic.

Most of Law boils down to a cascade of intermingled conditionals, nothing a computer couldn't handle.

Of course a bit of human intervention will always be required, for value judgements and the "hard questions".

However, in my (limited) experience with lawyers, very little of the time and money that a lawsuit consumes goes into the actual decision making.

The overwhelming majority is wasted on process and formalities.

There is no single source of truth. Every court case creates a new version of kaw, called case law.

Well, the body of this case law (and all other laws) is what I refer to as "single source of truth".

Yes, "single source" is very much an euphemism.

In practice it's far from a single source, but rather a poorly synchronized mess. Which is exactly what I'm proposing to fix.

If we were to wrap it into a github-style model then cases could be represented as branches. Case-law would evolve in the form of patches and pull-requests.

FIX often standardize everyone's favorite custom fields after few years. The problem is that nobody is upgrading yet keep adding custom fields to their implementation, even worse sometimes back-porting tags from newer version but in incompatible ways (5.0 SP2 was released on 2011, but I've never worked with anything above 4.2 that was released 15 years ago.)

Naive first thought: it seems like an active standards body is required. Like for HTML. That took care of e.g. The CENTER tag.

There is one. It cannot possibly move as fast as all the individual actors. Standards bodies can provide high quality at slow pace. Participants here want fast pace and only adequate quality.

Reply on news.ycombinator.com