##Sample data file
---
module : ContractModel
---
let billsAddress:
Address street: 44 East 5th Ave
city: Vancouver region: BC country: Canada
postal: V6R-2T5
Contract number: 34343
start: 2009-05-01
provider:
Company name: Cedar Systems
phones:
1: Office 604 897 9729
2: AfterHours 604 897 9729
site: http://www.cedar.com
incorpLoc: Alberta
beneficialOwners:
1: Person name: Joerg
id: 81a130d2-502f-4cf1-a376-63edeb000e9f
ipAddress: 10.0.0.12
eMail: None
phone: Mobile 604 897 9729
dob: 1967-03-27 sex: Male
occupations:
2: Company name: Acme Holdings
phones:
site: None
incorpLoc: Alberta
beneficialOwners:
1: Person name: Cindy
id: 51a130d2-502f-4cf1-a376-63edeb000da1
ipAddress: 10.0.0.11
eMail: [email protected]
phone: none
dob: 1961-04-2 sex: Female
occupations:
holder:
Person name: Bill
id: 8f76ba2d-f5e9-4c28-a145-b42325be1ea7
ipAddress: 2001:db8:a0b:12f0::1
eMail: [email protected]
phone: None
dob: 1988-05-01 sex: Male
occupations: 1: Doctor 2: Pilot
address: billsAddress
Editor gives option to create new where ever a record is expected.
- root populated by default
- record fields
- after a let, this is used to create records that will be reused.
When selecting "new" command a new record is full dropped in with
- None for options
- Some placeholder for other values such as Strings, Ints, DateTimes etc. Not sure how this will work. Need an invalid but plausible looking value for all basic types.
- Tuples a pair of plausible values.
- Choose for union types with choice of cases
- Choose where one or more let defined records will fit
Records defined in a let and then reused in root will be written out that way when "pretty printed"
Record types are always introducted by a lable and then begin on the next line.
Type anotation are not needed. However since a union constructor is needed it appears such an anotation is needed when introducting a union case. For example Person or Company.
Items defined in let bindings but not used are an error.
There is no explicit separator character. Separators are:
- For records the list of all possible <field name values.
- For lists the tokens <integer
- For tuples <dash NOTE: this is not the greatest as "dash" is not uncommon.
No such values may appear in any of the data elements. If any data element requires such a value it must be entered as a tripple escabled string.
The last item defined is returned as the value of the document.
When serializing back should they system perform automatic extraction of equal values?
The fson representation should be convertible to json representation using the following rules: *...
Arbitrary simplifications
- No record types or lists into tupples. Tupples are only for simple pairs like: 'Mobile - 604 234 2233' where the tuple is a phone type and a number.
- Actually perhaps no need to support tupples at all. They are not a very strong modeling concept