Meeting minutes
Minute check from last week
<sebastian> https://
Sebastian: quick look at issues
… postponing some of them to v2
… some PRs
… including ReSpec errors
… also relation types
… cardinality
… still ongoing
… then security
McCool: yes
Sebastian: then multiple op values
… and several issues
… reliability
McCool: need an expert
Kaz: I'm now contacting the IEC expert as well
McCool: related to geolocation and time series data
Sebastian: ok
… we'll continue the discussion
<sebastian> any objections to bring the minutes to public?
<sebastian> no
approved
Defer issue to TD 2.0
Sebastian: let me know if any problems
PR 1038
Sebastian: we can't change the TD REC itself
… this is a tentative URL
McCool: this PR itself wouldn't solve the actual problem?
… do we want to use one specific schema for both v 1.0 and v 1.1?
… having two ones separately would make sense
Cristiano: right
Ege: combo schema should be also removed then?
Kaz: if we really need to update the 1.0 REC for implementations, we need to update the 1.0 REC
… but if not, we don't have to do so
… and having a separate schema for v1.1 is fine
… note that at some point maybe in 2 years, there is a possibility we even might want to deprecate the v1.0 REC
… so we should think about our timeline as well
Sebastian: (adds comments to PR 1038)
PR 1031
Preview of 5.3.3.6 APIKeySecurityScheme
Sebastian: (goes through section 5.3.3.1)
Preview of 5.3.3.1 SecurityScheme
McCool: think it's ready to merge
Sebastian: (merges it)
prsent+ Michael_Koster
PR 1032
McCool: (goes through his recent comments)
McCool: not ready for merge and would update it
Preview of 5.3.3.6 APIKeySecurityScheme
Kaz: the first row is broken
McCool: will fix it as well
… working on it
(Farshid joins)
PR 1038 (revisited)
Sebastian: note that we've just talked about your PR 1038
Farshid: can the schema upper compatible?
McCool: we can bug-fix it if needed but not really upper compatible
McCool: we need some unified validation mechanism
… but having the two different schemas would make sense
… though we need to fix bugs
… from my viewpoint, accepting the two schemas is OK
Sebastian: then I'll remove the comment inside the "Files changed"
<McCool> I feel we should use a w3c URL for the schema, not github
<cris> +1 also from my side... also full github address with the commit hash is super long :)
Kaz: I don't really recognize any concrete/big differences between (1) the resources are installed on the W3C server and (2) installed on GitHub with a redirection from some W3C URL
(we need to discuss our policy a bit more)
PR 1024
Sebastian: comments from Jan Romann, a student from Carsten's lab
Sebastian's response to Jan's comments
Sebastian: wo kind of imports are necessary:
… an "extend" import to have the full definition of an other existing TM. For that the link container can be used with 'rel=extend'
… an import mechanism that allows to import sub-definitions of other existing TMs. This is the direction that is explained here.
<Ege> https://
McCool: we just do Thing Model and use TD for instanciation
Sebastian: need to leave now...
Ege: can postpone till the next call
… but there is a related issue 168
Ege: import/extend functionality in TD
Sebastian: Thing Model is used to generate a valid TD
McCool: let's continue the discussion using GitHub, etc.
Sebastian: ok
… let's continue the discussion next week
[adjourned]