2015-05-21 Tech Meeting Notes

Owned by Mark Lizar (Unlicensed)
Last updated: May 21, 2015
2 min read

Date

May 21, 2015

Attendees

Agenda:

  • Admin: call time and mtg schedule
    •  call time for next week is at 7pm UK time, 11 PST, 2pm est
  • Discuss approach/strategy to developing technical aspects of the specification
    • we just thought we would dive in and start throwing json fields at it and running examples against the data model
  • The current MVCR: Core profile Draft (MVCR use/explanation outline)  (very early draft)
  • List of actions needed to complete the technical specification  and a plan to achieve the actions
    • The MVCR draft now has the json model and an example, the homework, is to start running scenario's against the model

In this call we went through the fields, but some json against them, then made an example. Talking through various elements.

Notes

  • Justin: clear separation between the data model and the rendering of the data model
  • lots of discussion about the end rendered state instead of what the expression of this is as a data model
  • little thought about what canonical form 0
  • looking at this as a receipt that is generated as a per transaction basis -
  • great - and foundational work - need to ensure that this data model is the primary construct and everything else is a derivative context
  • with the data model – can define presention layers, the API's, the public precept and the non-public 
  • a good example :
    • https://mkjwk.org/ - this shows that the data model is can be rendered for both parties, rendered for presentation, and then stripped of private data and presented publicly as a public usable record.
    • with this above model, then we can have all the private information, or not,  (e.g. addressing Issue 3 for Nat, Iain, Mark and Robin all at once. )so that we can have all the personal data and company data in the payload, wrap this into a presentation mode for a human readable receipt, then strip out the personal data for a public token.
  • map use cases to the data model and if there is an issue then we raise and modify the data model - or evaluate weather we really need that information in the use case.