toby.bryans commented

Owner

There should be a version of the lm file format, and the lms file format included in both files for renders to understand what version of the standard they are rendering to
~~Is the escape on the pipe correct, should it be | not | ?~~
I think we'll need a proper multiline code block with similar code formatting like markdown (eg ```bash) so that renderers can choose to render with syntax colouring if they choose to.
Contents page generation (we already need multi pass compilation I think due to the internal references that may refer forward)?
Add ability for other local effects, such as colour, and possible temporary font changes in text, or should these be defined in the lms file and then allow temporary effect setting within a block or even ? I think the latter is probably better - see comment below.
Allow for striping of rows in tables
Headers and footers including page numbers, document version, dates etc.
Background images for eg corporate logos on cover / title page
Cover / title page layout and formatting controls
Page break controls on section / appendix style level (eg sections and appendicies should / should not start a new page, configurable respetively)
Orphan / widow control
Font feature controls (ligaments, ranged / old style numbers etc)

1. There should be a version of the lm file format, and the lms file format included in both files for renders to understand what version of the standard they are rendering to 2. ~~Is the escape on the pipe correct, should it be \| not | ?~~ 3. I think we'll need a proper multiline code block with similar code formatting like markdown (eg ```bash) so that renderers can choose to render with syntax colouring if they choose to. 4. Contents page generation (we already need multi pass compilation I think due to the internal references that may refer forward)? 5. Add ability for other local effects, such as colour, and possible temporary font changes in text, or should these be defined in the lms file and then allow temporary effect setting within a block or even ? I think the latter is probably better - see comment below. 6. Allow for striping of rows in tables 7. Headers and footers including page numbers, document version, dates etc. 8. Background images for eg corporate logos on cover / title page 9. Cover / title page layout and formatting controls 10. Page break controls on section / appendix style level (eg sections and appendicies should / should not start a new page, configurable respetively) 11. Orphan / widow control 12. Font feature controls (ligaments, ranged / old style numbers etc)

ben.weiner commented

2026-01-29 21:37:39 +00:00

On (5) you really want to pull in an existing spec to cover 'freeform' typographical changes I suspect. Allowed in block level elements.

toby.bryans commented

2026-01-29 21:44:54 +00:00

Author

Owner

@ben.weiner

As in make it even closer to css?

I think you could probably go with something like:

effect red-text {
  font-colour: #ff0000
}

And then inline in the document block something like this:

Lorem @effect(red-text){ipsum} doler sic amet

Of course they will need to be nestable, too:

Lorem @effect(red-text){ @effect(serif-font){ipsum}} doler sic amet

@ben.weiner As in make it even closer to css? I think you could probably go with something like: ``` effect red-text { font-colour: #ff0000 } ``` And then inline in the document block something like this: ``` Lorem @effect(red-text){ipsum} doler sic amet ``` Of course they will need to be nestable, too: ``` Lorem @effect(red-text){ @effect(serif-font){ipsum}} doler sic amet ```

ben.weiner commented

2026-01-30 18:16:21 +00:00

OK so extend legalmark directly, rather than take features from elsewhere. Seems OK.

To me 'typographical' means font weight, size, style - but can't see any point in excluding colour!

OK so extend legalmark directly, rather than take features from elsewhere. Seems OK. To me 'typographical' means font weight, size, style - but can't see any point in excluding colour!

toby.bryans commented

2026-02-11 18:15:38 +00:00

Author

Owner

OK so I'm going to split these into release 1 and release 2:

release 1

There should be a version of the lm file format, and the lms file format included in both files for renderers to understand what version of the standard they are rendering to
Contents page generation (we already need multi pass compilation I think due to the internal references that may refer forward)?
Add ability for other local effects, such as colour, these should these be defined in the lms file and then allow temporary effect setting. See example below.
Allow for striping of rows in tables
Headers and footers including page numbers, document version, dates etc.
Page break controls on section / appendix style level (eg sections and appendicies should / should not start a new page, configurable respetively)
Font feature controls (ligaments, ranged / old style numbers etc)

release 2

A proper multiline code block with similar code formatting like markdown (eg ```bash) so that renderers can choose to render with syntax colouring if they choose to.
Cover / title page layout and formatting controls
Background images for eg design on cover page, or on page template
Orphan / widow control

Example of local effects

Something like:

effect red-text {
  font-colour: #ff0000
}

And then inline in the document block something like this:

Lorem @effect(red-text){ipsum} doler sic amet

Of course they will need to be nestable, too:

Lorem @effect(red-text){ @effect(serif-font){ipsum}} doler sic amet

OK so I'm going to split these into release 1 and release 2: # release 1 - There should be a version of the lm file format, and the lms file format included in both files for renderers to understand what version of the standard they are rendering to - Contents page generation (we already need multi pass compilation I think due to the internal references that may refer forward)? - Add ability for other local effects, such as colour, these should these be defined in the lms file and then allow temporary effect setting. See example below. - Allow for striping of rows in tables - Headers and footers including page numbers, document version, dates etc. - Page break controls on section / appendix style level (eg sections and appendicies should / should not start a new page, configurable respetively) - Font feature controls (ligaments, ranged / old style numbers etc) # release 2 - A proper multiline code block with similar code formatting like markdown (eg ```bash) so that renderers can choose to render with syntax colouring if they choose to. - Cover / title page layout and formatting controls - Background images for eg design on cover page, or on page template - Orphan / widow control # Example of local effects Something like: ``` effect red-text { font-colour: #ff0000 } ``` And then inline in the document block something like this: ``` Lorem @effect(red-text){ipsum} doler sic amet ``` Of course they will need to be nestable, too: ``` Lorem @effect(red-text){ @effect(serif-font){ipsum}} doler sic amet ```

ben.weiner commented

2026-02-20 08:10:01 +00:00

@toby.bryans here is a response from my friend the barrister.

Dear Ben,

this is an interesting endeavour. I should note at the outset that the sort of work that I do very rarely involves drafting contracts: I specialise in contentious work, whereas drafting contracts is normally done by those who specialise in non-contentious work. I am, however, sometimes involved in drafting agreements to settle contentious claims. I set out below some initial thoughts about this.

Of primary importance would be cross-compatibility. Any firm of solicitors using any given document system would have to be able to inter-operate with any other firm of solicitors anywhere in the world. The data format needs therefore to be highly compatible. If one firm is using something very niche that the counterparty to the negotiations is not using, the format is of no use. Time will be wasted in creating a document in a niche format if there is a real risk that it will have to be converted to a mainstream format to be compatible with the counterparty's solicitors systems.

It is not clear from the specification whether what is being described is the underlying document data, or the UI, or some combination of both. Generally, lawyers do not have a deep technical understanding of computers, so anything requiring them to be able to edit raw code rather than use a WYSIWYG interface that is very easy to use is very unlikely to succeed in the legal market.

The format needs to be capable of very long-term archiving. If there is a non-negligible risk that the software needed to make sense of the formatting will not be readily available on any successor practice or client's computer in 10-20 years' time, then the format is not likely to be successful.

It is not immediately clear (perhaps I have missed it) how this resolves one of the main limitations of current generation word processors, which is that they do not handle large numbers of rounds of tracked changes cleanly, and it can be difficult to cross-reference paragraph numbers in different versions of a document. For example, if we have: (1) Foo; (2) Bar in version 1, and in version 2 we have (1) Foo; (2) Blibby; (3) Bar, if in version 3 we need to make a change to "Bar", it can be ambiguous whether we need to refer to paragraph 2 or 3, depending on which version that we are using. This is an inherently hard problem to solve.

Lawyers' time is generally extremely expensive. If significant time is to be needed needed for training to use this system, there would need to be a demonstrably very high return on that investment that can clearly be proven, as training time cannot be billed to clients. Likewise, the system is unlikely to succeed unless it can demonstrably save very significant amounts of time. This may require extensive empirical testing in real world situations to establish.

There would need to be a very clear and precise explanation of the limitations in current software and exactly how this system overcomes them and why overcoming those specific limitations is worth what I suspect may be very significant training costs to persuade a legal firm to adopt a fundamentally new system (i.e. one whose interface is not already familiar to those who work there without additional training).

Automatic numbering and automatically updating cross-referencing are features that already exist in word processors and routinely used in legal documents, and likewise automatic numbering of nested lists, so these are not by themselves features that would justify the cost of switching to new software; likewise, electronic signature software already exists in the PDF.

Having two separate files to store the data may well complicate the process of sending the files by e-mail (imagine somebody sending one but not the other, or sending the wrong version of one of the two files, for example - or sending one but not the other when the recipient has an older version of the other).

Only tiny minority of lawyers will be able to code in Python to take advantage of the feature proposed in paragraph 18.1. Depending on the environment in which such code executes, having code embedded in the file may be considered a security risk in some cases.

As to the conditional content in version 18.5, this would need careful thought to prevent a situation where one party believes that a section is included and another party believes that that section is excluded from the document. In other words, it is usually very, very critical to put beyond any conceivable doubt that all parties have very, very precisely the same document. Conditional content strikes me as something that could put that certainty at greater risk than a system that does not have it. The precise conditions in which the variable has the value to show or hide the content would become critical, and this may not be 100% transparent to lawyers with limited technical knowledge (or, indeed, to clients). Also, those conditions would need to be extremely clearly defined and ultra-reliable.

I hope that this is helpful and that you are keeping well;

yours sincerely

James

@toby.bryans here is a response from my friend the barrister. > Dear Ben, > > this is an interesting endeavour. I should note at the outset that the sort of work that I do very rarely involves drafting contracts: I specialise in contentious work, whereas drafting contracts is normally done by those who specialise in non-contentious work. I am, however, sometimes involved in drafting agreements to settle contentious claims. I set out below some initial thoughts about this. > > Of primary importance would be cross-compatibility. Any firm of solicitors using any given document system would have to be able to inter-operate with any other firm of solicitors anywhere in the world. The data format needs therefore to be highly compatible. If one firm is using something very niche that the counterparty to the negotiations is not using, the format is of no use. Time will be wasted in creating a document in a niche format if there is a real risk that it will have to be converted to a mainstream format to be compatible with the counterparty's solicitors systems. > > It is not clear from the specification whether what is being described is the underlying document data, or the UI, or some combination of both. Generally, lawyers do not have a deep technical understanding of computers, so anything requiring them to be able to edit raw code rather than use a WYSIWYG interface that is very easy to use is very unlikely to succeed in the legal market. > > The format needs to be capable of very long-term archiving. If there is a non-negligible risk that the software needed to make sense of the formatting will not be readily available on any successor practice or client's computer in 10-20 years' time, then the format is not likely to be successful. > > It is not immediately clear (perhaps I have missed it) how this resolves one of the main limitations of current generation word processors, which is that they do not handle large numbers of rounds of tracked changes cleanly, and it can be difficult to cross-reference paragraph numbers in different versions of a document. For example, if we have: (1) Foo; (2) Bar in version 1, and in version 2 we have (1) Foo; (2) Blibby; (3) Bar, if in version 3 we need to make a change to "Bar", it can be ambiguous whether we need to refer to paragraph 2 or 3, depending on which version that we are using. This is an inherently hard problem to solve. > > Lawyers' time is generally extremely expensive. If significant time is to be needed needed for training to use this system, there would need to be a demonstrably very high return on that investment that can clearly be proven, as training time cannot be billed to clients. Likewise, the system is unlikely to succeed unless it can demonstrably save very significant amounts of time. This may require extensive empirical testing in real world situations to establish. > > There would need to be a very clear and precise explanation of the limitations in current software and exactly how this system overcomes them and why overcoming those specific limitations is worth what I suspect may be very significant training costs to persuade a legal firm to adopt a fundamentally new system (i.e. one whose interface is not already familiar to those who work there without additional training). > > Automatic numbering and automatically updating cross-referencing are features that already exist in word processors and routinely used in legal documents, and likewise automatic numbering of nested lists, so these are not by themselves features that would justify the cost of switching to new software; likewise, electronic signature software already exists in the PDF. > > Having two separate files to store the data may well complicate the process of sending the files by e-mail (imagine somebody sending one but not the other, or sending the wrong version of one of the two files, for example - or sending one but not the other when the recipient has an older version of the other). > > Only tiny minority of lawyers will be able to code in Python to take advantage of the feature proposed in paragraph 18.1. Depending on the environment in which such code executes, having code embedded in the file may be considered a security risk in some cases. > > As to the conditional content in version 18.5, this would need careful thought to prevent a situation where one party believes that a section is included and another party believes that that section is excluded from the document. In other words, it is usually very, very critical to put beyond any conceivable doubt that all parties have very, very precisely the same document. Conditional content strikes me as something that could put that certainty at greater risk than a system that does not have it. The precise conditions in which the variable has the value to show or hide the content would become critical, and this may not be 100% transparent to lawyers with limited technical knowledge (or, indeed, to clients). Also, those conditions would need to be extremely clearly defined and ultra-reliable. > > I hope that this is helpful and that you are keeping well; > > yours sincerely > > James

toby.bryans commented

2026-02-20 14:24:27 +00:00

Author

Owner