Meeting minutes
TD
GitHub problem with PR templates
<kaz> PR 2078 - PR Template not working
<kaz> PR 2079 - Moving the PR template one level up
Ege: there is no real fix, PR 2079 is a work around
… any objections to merge?
… merged
Ege: works now
Initial connection container
<EgeKorkan> PR 2058 - Initial Connection Feature Description
Ege: made some progress, looking for feedback on the progress so far
… would like to merge now because there are a lot of changes
<kaz> Rendered MD
Ege: (explains how different shapes work)
… a string value is a reference, an object value is an in-line definition
… made the JSON schema and it has some issues
… the result is too many ways to write TDs
Ege: (shows examples of different code patterns)
… almost 10 different ways to express the same TD
Kaz: to clarify, these are examples to illustrate the md file
Ege: the examples are to test the outcome of the proposed mechanism
Kaz: it's confusing to call it tooling
… maybe call it a sandbox exercise. also would be nicer to describe there is a sandbox area and test data to verify the proposal within the README.md.
Ege: there are too many ways to do the same thing
… it makes it hard to detect invalid TDs
… the validity test is for lack of connection
… it's very difficult or impossible to model the specific logic we need in JSON Schema
… it needs to be tested with code
… the diverse patterns may make it difficult for humans to read
… (shows examples of testable vs. not testable patterns)
Daniel: maybe we can do it differently, apply the validation to a fully expanded TD
… don't bother with the intermediary forms
Ege: how do I know beforehand if a TD can be expanded?
Daniel: there could be code to try to expand the TD
Ege: it is still a problem to describe the valid combinations in the spec
… I can write a JSON Schema to validate the expanded TD
Cristiano: I had the same thought to validate the expanded TD
… thinking about the different stages of TD and validation at each stage
… does this actually make it easier to write TDs?
Ege: there is clear improvement in the simplest case
… the issue is the patterns between simple and fully expanded
Cristiano: the answer to validation before submitting is to have a code tool available along with the JSON Schema
… another question, what are we saying about the actual connection, is it kept alive?
Ege: no, the keep alive should be expressed in the binding
Ege: we could provide 2 JSON Schemas, one for the simple case and one for fully expanded
Mahda: one approach is to change the validation mechanism from JSON Schema and internally have a more expressive validation language
<mahda> https://
Ege: How can we include the JSON-LD expansion and compaction algorithms?
… does anyone know how it works on JSON-LD playground?
… (brings up Playground and tries some things)
Mahda: It tries to expand before validation
Ege: it looks like it tries to dereference URLs
Kaz: starting to wonder about the potential use of ThingModel
… is there a way to validate at the ThingModel level first in a 2 level approach?
Ege: ThingModel may only have a place holder, but the same patterns are possible in ThingModel. The validation may difficult.
… maybe there could be some information attached that the ThingModel is valid
Kaz: it's a good time to think about ThingModel and ThingDescription contexts
Ege: the main problem will be how developers do the expansion
… As for expansion, we are also talking about canonicalized TD, maybe this is the same as a fully expanded TD
Kaz: that's also a possible solution but it would be a tough burden to ask all the implementers to handle all the possible complex variations.
Cristiano: wondering if ThingModels are templates for expanded TDs
Ege: for the simple case, we would expect the TM to be in the expanded form
… maybe we should see how much people use the intermediate formats
… we should encourage either the simple form or the expanded form
Kaz: yeah, we should think about how we could make things simpler. we could learn from cases when people submit more complex TDs
… maybe there are common patterns we could describe
Ege: the last question is merging this PR, should we wait for the expansion script?
… no opinions, I will wait and make some more changes
AOB
Ege: is there any other business?
… hearing none, we are adjourned. Thanks everyone