Re: [T2TRG] Webex meeting invitation: T2TRG/WISHI work meeting 2019-10-04

[Carsten Bormann <[e-mail]>]

On Oct 3, 2019, at 09:17, Carsten Bormann <[e-mail]> wrote:
> 
> We haven’t done a full agenda yet, but it seems one item on that will be:
> 
> * Extract architecture from sdf.md
> 
> SDF is OneDM’s “Simple Definition Format”, which is the common format in which data models are going to be exchanged and agreed upon.  It is being developed at https://github.com/one-data-model/language
> 
> SDF has various components, including missing ones that still need to be defined.  A more formal view of what these components are, do, and how they interact, might help in making use of SDF and in further refining it without losing architectural integrity.  Of course, we also might be able to identify gaps/opportunities for further development.

Numbering the above as (1), a few more items that came up:

* (2) Terminology

This is, of course, closely related to architecture.  Can we further improve on the terminology used to describe SDF?  (E.g., one breakthrough this week was when we found that we have to distinguish “definitions” from “declarations”.)

* (3) JSON Pointers, CURIEs, Naming for Cross-Referencing within and between Specs

How does the spec refer to definitions done at a different point in the same spec or in a different spec?
The current spec provides a mix of RFC 6901 JSON Pointers (with the draft-handrews-relative-json-pointer-02.txt extension) and CURIEs.
Is there a way to clean this up and simplify it?

* (4) Breadcrumbs

We found that referring to some other part of the spec might not only simply want to copy the referred-to part, but also might want to preserve the identity (whatever that is) of the referred-to part.  Is preserving the JSON pointer (after normalizing it to absolute/CURIE resolution) all that is needed?
(This is related to the age-old issue of “name equivalence” vs. “structural equivalence”.)

* (5) Semantic Processing

What else do we need to enable reasoning on the results of applying an SDF spec to an interaction?

* (6) Versioning of Model Specifications

OneDM hasn’t tackled the difficult issue of versioning of model specifications yet.
There are interesting potential objectives for versioning beyond simply keeping track of them the way git does, e.g., how can a spec be updated and that update become usable for other specs making use of the original spec?  Does “semver” (semantic versioning, https://semver.org, draft-claise-semver-02.txt, draft-verdt-netmod-yang-semver-00.txt) help?
Is there some advice we can give?

* (7) Reuse

Probably closely related to versioning: How can we maximize reuse of specification components (within a spec, between specs, over time, …)?  Derivation is one way (may be closely related to what is called inheritance in object oriented languages); how does that work precisely; are there other ways?


We may not be able to usefully address all of these issues today, so some triage/prioritization will be needed when we start at 0900 CEST == 0700Z.

There is going to be a somewhat extended lunch break as some of us will be involved in giving a talk from 1300 CEST to 1400 CEST (1100Z..1200Z).

See you in (a bit less than) three hours…

Grüße, Carsten