Meeting minutes
Some updates on JSON schema validator
<EgeKorkan> PR 2080 - fix: align JSON Schema with JSON-LD @context format
Registry entry dependencies
<EgeKorkan> Binding Issue 401 - Handling Bindings that depend on other bindings
Ege: issue #401
Ege: what happens when >1 binding uses another binding, e.g. CoAP
… the general idea is that we should not override the shared binding
Cristiano: agreed, we should not allow a user of a binding to override. If extension is needed in the depended binding, it should be collaboratively extended
Jan: there could also be a dependency chain
… could there be multiple dependencies?
Ege: for example, XML-RPC and HTTP
… what about the terminology, dependee
Jan: can't think of anything much better
Ege: marking as PR needed
Issue #404, required machine readable documents
<EgeKorkan> Binding Issue 404 - Required Machine Readable Documents for Registry Entries
Ege: proposal to require a JSON Schema to validate the form
… Ontologies and other diagrams are recommended but optional. If provided, they are required to be reviewed
… all documents must be listed in the summary
Cristiano: we need to keep in mind that there could be required items beyond the form
… we should generalize the text for required elements
Ege: (makes changes)
Cristiano: if new terns are defined, will a context be required?
Ege: as long as URLs resolve there will be no errors
Cristiano: there would be no JSON-LD expansion of terms, seems broken
Ege: we could require a context for new terms
Cristiano: node-wot would work, for example
Ege: we are strongly recommending the context
Ege: (shares MQTT example for review)
Ege: it seems not to be a big issue
Cristiano: there could be issues in downstream processing
… maybe we could provide a warning
… We don't have a lot of test cases in the user base
Ege: the core ontology is being used by people as RDF
… it's a small user base
Jan: should the submission include a well-known prefix to mitigate the JSON-LD issue?
Ege: adding label for PR Needed to issue #404
Ege: assigned to Koster
PR #2058, initial connection
<EgeKorkan> PR 2058 - Initial Connection Feature Description
Ege: the problem is that unexpanded document elements are difficult to validate
… added schemas to require expanded elements
… and disallow top level defaults
… to make sure the expansion is complete
… (walks through the schema to review the specific cases)
<kaz> tds.js from PR 2058
Ege: there is still one TD that is not being failed when it should
… limited to the security definition
Ege: validating the expanded TDs makes the most sense
Kaz: meta-comment, this is a big PR and still being worked on. Could we merge what we have?
Ege: yes, makes sense
Cristiano: looks like the right direction to validate the expanded TD
… it could be very verbose but expanded from a very compact and human readable TD
Ege: there could be errors in expansion that prevent validation
… (refactoring the JS expansion/validation code)
Ege: we agree on the approach of validating the expanded TD
Ege: we can continue to work on the code and adjourn the call
Ege: adjourned