-
Notifications
You must be signed in to change notification settings - Fork 1
/
Specification
146 lines (105 loc) · 7.27 KB
/
Specification
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
CommonAccord -- Public law, private data
Overview and Technical Specification
Crowd-sourced from:
@hazardj
________ (your name here)
For background, see:
commonaccord.wordpress.com and beta.commonaccord.org/wiki see some examples at http://lun-sandbox-cma-concept1.appspot.com/document/Tree_DocList
THE GOALS:
Make lists and outlines, not documents!
A general system of editing and managing documents that has the versioning features of git and the semantics of multiple inheritance. Permitting users to create, negotiate and manage documents and pages as short outlines that render into the full text.
Thereby:
making legal solutions immediately available to everyone
open sourcing the content and software of transacting
returning control of dealings and data to participants
making information semantically searchable
E.g., enable:
rapid, secure, collaborative dealing
better confidentiality
better knowledge management
direct access to legal "reality" (the user's situation and options)
systematized decision-making
peer-to-peer e-commerce without hubs
comprehensive descriptions of legal relationships, globally
Basic architecture:
A data model implemented in various formats and systems, interoperating. E.g.,:
Wikis for forms and libraries (wide collaboration)
Tables on web pages (e.g., contact info and product offerings)
Email threads (versioned objects for transacting)
Local files (word processing)
Integration with databases and other systems
Integration with authoring systems
Rendering will often be done on the client side, in an app, application or command line
git
HOW TO HELP:
Make contributions of tech or text (see below).
Support a structure for CommonAccord.org.
Use the data model and the legal code.
Talk to folks who “own” part of the problem -- corporate counsel, small business, do-gooders.
AREAS OF WORK:
Improve the data model and implement the semantic web (described below)
Models of legal forms, libraries, naming schemes
Formats for data such as addresses, things, persons
Governance
See Technical Specification - next page
TECHNICAL SPECIFICATION:
Below are examples of (i) a document, (ii) an index. These are somewhat more advanced than currently implemented.
Rendering a list (or nested lists - an outline) into a document consists of (a) creating enough of its NameSpace and (b) substituting {spans} of text based on key/values in the NameSpace.
Substitutions can be done at four levels:
1. Make substitutions for {{Spans}} in the list;
2. Make substitutions for [Spans] inside of {Spans}, e.g. {[Buyer].Name.Full} becomes {Acme.Name.Full}
3. Make substitutions for {Spans}
4. On the fully rendered text, "hard-overrides" -- pure substitutions -- notably to deal with some </li></ol>;</li></ol> issues and for "{Acme.Name.Full}." where "Acme.Name.Full=Acme Corp." Creates a double period. These are like search and replace and can have unforeseen effects. Use sparingly.
In each case
NameSpace = Each pair (key/value) in (i) the list and (ii) each other list referenced in the list (iii) recursively.
Note that the method of exploring the NameSpace must be frugal. There can be circularity in lists referencing one another (many circumstances in which this is correct) and some lists will reference many other lists. (Circularity between two fields is an error.)
The NameSpace is organized three ways:
1a. By key: (primary method) Each key in the list and each key in each included list is part of the NameSpace. If the included list is prefixed, then each key in the included list is prefixed (recursively). If the prefix for the list is /commented/, then each key is also included without the prefix. There may be (will be) multiple keys with the same name. The bottom-most one wins. It is as if the system read up from the bottom and stopped at the first matching key.
1b. The second priority key can be accessed by a suffix .-1.
2. Each key can be addressed by position in the list -- {3:2:Name.Full} returns “Y-Combinator”.
3. @YCombinator.Name.Full returns “Y-Combinator”. To deal with spaceless uses, the notation can also be “nowadays {@YCombinator.Name.Full}s are popping up ….”
A list (document) is “frozen” when each @List (@Person, @Thing, @Form) used in rendering the list has been reduced to a @GUID. Otherwise, it is “fluid.”
The two lists below can be merged.
Let's improve on this.
(This looks awkward in the raw text format. It looks pretty good in an email, using outlining.)
CMACC/ &MyDeal #000223
1. Doc.Body=<center>{Agt.Prologue}</center><ol><li>{Agt._Sec.S}</li></ol>{Agt.Signature}</br>{Agt.Attachment}
1. Agt.
1. Prologue={Title}</br>between {Pcpl.[ID]} and {Cttr.[ID}
2. /Parties/
1. Pcpl.
1. @AcmeInc
2. Cttr.
1. @YCombinator
3. /Form/
1. @YCombinator_SeriesAA_Pref_Closing_Docs // if ok with you
2. Dispute.
1. &Juris_Court_USA_CA_SanJose // our preference
4./Misc/
1. ID=Name.Full
/CMACC
An index of documents:
Items in {{2xbraces}} are expanded before evaluation of the NameSpace
CMACC/ #000101
1. Beta=beta.commonaccord.org
2. BetaID=http://{{Beta}}/w/index.php?title=Main_Page&action=edit&oldid=
3. &Juris_Court_USA_CA_SanJose
1. {{BetaID}}4774
2. {{BetaID}}4779
3. {{BetaID}}4780
4. @AcmeInc
1.@000033
2.@000034
5. @YCombinator
1.@000055
2.@000076
/CMACC
Rendering:
Rendering is done by starting with a specified key (e.g., "{Doc.Body}") and doing replacements until exhausted (tokens replaced or marked as unfound).
Items in square brackets embedded between curly braces are evaluated before the curly braces ( above "{Pcpl.[ID]}" becomes "{Pcpl.Name.Full}" then "Acme Incorporated" ).
It is possible but not necessary to make it one list per page, for instance in a wiki (conflate the notions of pages and lists). And therefore to make the wiki page naming system be a proxy for an index. Mediawiki matches a URL with a GUID (permanent id).
There is a visual metaphor of a succession of semi-transparent pages or screens, one in front of the other. The user opens a list - which is screen 1, and each included list is a screen half-behind screen 1. As soon as you start work, there is a virtual list 0 (and screen) that saves the work. A commit saves that list 0 and repoints list 1 to the new list. One can commit as a new version of list 1 (if one has privileges) or give the list a new name. The versioning of the index could be done (i) locally in the new list, (ii) by creating a new index that versions the prior index, or (iii) by adding at the bottom of the existing index (with metadata about author and time). (i) and (iii) seem appropriate in different circumstances. (ii) seems pure but complicated?
Meta data:
The same data model can be used for its own versioning, organizing lists in non-exclusive trees, tagging. This keeps it uniform and fully distributed. It also avoids unnecessary exclusivity of tree organization and the like.
Other functions:
There is a need for other functions, such as spreadsheet-like automation (sums, averages, etc.) and database accesses (list of products or customers). Rather than create a new vocabulary, one should simply pass a {! token} to a list that is an interface for a programming language or database. Lisp seems to fit nicely for programming, but others may have different choices.