28 April 2021


Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Kaz_Ashimura, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Tomoaki_Mizushima, Victor_Charpenay

Meeting minutes


Sebastian: main task today will be preparing for our TD 1.1 WD update

review minutes Apr 21

<kaz> -> https

https://www.w3.org/2021/04/21-wot-td-minutes.html Apr-21

Sebastian: was canonicalization merged?

McCool: yes, but were some minor issues, so I made issues and a PR to address some of them

Sebastian: what about validation?

McCool: validation still WIP, will really only finalize after testfest when we are sure what can be automatically tested

Sebastian: any objections to publishing the minutes?
… no objections, will publish.

publication plan

Sebastian: still have one week to bring in new features, then will be making call for review
… aiming for resolution on May 19 for a new WD


PR 1077

PR 1077 - WIP: Extend JSON-LD context to allow for round-tripping to/from N-Triples

Sebastian: what is status?

Victor: still in progree

Sebastian: think it can be finished by next week?

Victor: maybe
… no impact on the draft itself; is ontology work

McCool: would be useful to have framing normative for directories

Victor: what is being frozen this week?

McCool: discovery is not frozen yet, the WD is just an update
… also, JTD, just published, is a good place to direct testing for framing

McCool: see also some issues about array ordering being maintained
… please look at new assertions on TD Processors in Canonicalization section

PR 1095

https://github.com/w3c/wot-thing-description/pull/1095 PR 1095 - Two step generation of the TD from a TM

generation of TD from TM

Sebastian: created a set of assertions for each step

McCool: note that we need two implementations for everything...

Cristiano: have tried to frame this process so we can test the output
… don't force implementers to actually use the two-step approach

McCool: is everything testable with JSON Schema?

Cristiano: not sure, the "extends" relation may be tricky
… also, last step about filling in forms may be difficult

McCool: also security; "securityDefinitions" might be defined separately, then combined with the TM to create the TD (by selecting security scheme definitions for each interaction)

McCool: I see though that the wording is based on the output, so...

McCool: I find "complemented" a little vague, but will have to think if there is better wording that would be more specific

Sebastian: still this is a big improvement over the current draft

Sebastian: suggest we merge and iterate

McCool: also ok with that

Cristiano: however some issues with running the renderer... CLI does not quite work
… opened issue #18 on vc's repo

Sebastian: ok, will merge

PR 1098

PR 1098 - Fix multiple TD model definitions

Sebastian: this fixes various things that suddenly became arrays, base went missing, securityDefinitions missing, security changed to an object instead of a string, etc.
… so this PR brought back all these missing definitions

McCool: can confirm that security and securityDefinitions are now correct

McCool: +1 on merging, critical for other things I want to get done...

Sebastian: merging

McCool: would be nice btw to have a directory structure that clearly distinguished input and output files

Victor: are comments in the render script

PR 1099

PR 1099 - fix: default op values for HTTP

added readOnly to the example

the HTTP protocol binding, simplifies things

McCool: see ege has reviewed

Sebastian: merged

PR 1102

PR 1102 - Update Terminology Section

mention Thing Model, Partial TD, etc: say definitions are defined in Arch document, and removes it from TD spec, so there is a single place where the definition is made, in Architecture

McCool: I think the future we should get rid of the etc.

Sebastian: agree

McCool: ok for now, though

Sebastian: let's edit it and remove the etc. now; also need to resolve conflict

Sebastian: (fixes both problems)

Daniel: should terms be in lexi order?

Sebastian: semantic clustering seems to work better, will leave it that way
… conflict was just about introduction of Thing Model, resolved.

Sebastian: merged

PR 1103

https://github.com/w3c/wot-thing-description/pull/1103 PR 1103 - Introduce Thing Icon

Sebastian: updates relation type with new entry, "icon"
… and it is an IANA name
… also added tm: to tm:extends
… also new entry in Links, "sizes", to give different sizes for icons; sim to HTML

McCool: HeightxWidth should be Height x Width
… or maybe {Height}x{Width}

Sebastian: can make that edit...

Sebastian: seems I also forgot to edit the template... (fixes)
… never mind the definition needs to be edited in the ontology, not the template...
… and the validation...
… (done)
… there is a conflict, but is index.html, not critical (generated)

Sebastian: merged

Cristiano: should we be adding some validation about this to the JSON schema, e.g. for sizes?

Sebastian: that would be nice

Cristiano: I will try to update the JSON schema appropriately

Sebastian: coordinate with Ege

McCool: may need to add some tests

PR 1104

PR 1104 - Address multiple DataSchema issues

Sebastian: no pattern, and also a bug (maxLength should apply only to strings)

Sebastian: discussion related to general compatibility with JSON schema; should we have full compatibility?
… right now we cover most/all of it
… not far away from full compliance

Ege: I will look into it, I also don't think it's a lot

McCool: I think we should specify the DATE at which we were aligned, and the exceptions (eg no support for $ref, etc)

Sebastian: also we use "default"...

McCool: not clear if "default" is now in the JSON Schema spec; perhaps Ege can check while he is doing the feature review

<Ege> https://tools.ietf.org/html/draft-handrews-json-schema-validation-01#section-10.2

Ege: default is in the JSON Schema spec, but is an annotation

<Ege> https://tools.ietf.org/html/draft-handrews-json-schema-validation-01

McCool: also, are we citing the IETF (draft) version?
… we need to pick a specific version and make sure our reference is correct

Sebastian: ok, let's collect fixes and discuss merging next time

note this PR addresses multiple issues

Sebastian: also some issues about subset of JSON schema used, and whether additional terms can be used from JSON Schema; but without a prefix

McCool: I wonder if we should allow random vocab without a prefix
… if we insisted on having a prefix, then the validator could catch spelling mistakes, e.g. property/properties

Ege: we allowed extra stuff because lots of JSON Schemas have extra stuff in them that are not in the JSON Schema spec

Kaz: technically, all the additional properties other than the default namespace should be specified by the additional namespaces, e.g., JSON Schema. Also we should refer to the following latest IETF draft for JSON Schema Validation from TD.

<kaz> latest IETF draft for JSON Schema Validation (2020)

McCool: perhaps tools can have strict mode, but can turn off in case of extra stuff in schemas

Sebastian: there is another issue about "format" being removed from JSON Schema
… do we remove it from TD spec?

Ege: ok if stick to particular version
… there is also an issue with items

McCool: think we should stick to one version for 1.x, and update version in 2.0
… could mark "format" as deprecated though

Koster: we also should update the ontology; unfortunately JSON Schema does not provide an official ontology

Sebastian: suggest thinking more about this and will check next week

PR 1108

PR 1108 - consumer forms selection

Sebastian: how to deal with multiple forms. Added a paragraph providing guidance: pick one that works, use it as long as possible

Sebastian: merged

PR 1109

PR 1109 - restrict more uri variables

Sebastian: need to restrict URL for simple types

Sebastian: forbids use of objects and arrays

McCool: I had some minor nits, would rather see a class for "SimpleDataSchema", but having a comment is better than nothing

PR 1110

PR 1110 - Add contentType default to canonicalization examples

McCool: fixes bug in example, "contentType" has a default so needs to be included in canonical form

PR 1111

<kaz> PR 1111 - Add fracsec rule to dateTime in Canonical TD


this means that fractional seconds must be serialized according to JCS and must not have trailing zeros

PR 1113

PR 1113 - add tm:required and tm:ref generation

Ege: worked on tm:ref and tm:required

Ege: examples are only for interactions; can it be used elsewhere?

McCool: an example might be to have a TM with securityDefinitions that I can pull in...

Sebastian: in SDF, can it be used everywhere?

Koster: yes, it can be used everywhere, but the resulting object needs to be valid, i.e. you need to bring in an Object where and Object is expected

McCool: what about pulling in same thing twice? Do we pull in refs and then validate?

Koster: could have overrides

McCool: think we should have a general assertion that the result of dereferencing tm:refs should result in a valid file (TM or TD)

McCool: we could have simple rule that duplicates are not allowed
… could also do overriding, but more complicated to define

McCool: what is SDF rule?

Koster: overriding. new duplicate definitions replace existing ones
… but also say "meaning should not be changed"
… which is hard to test, so more user-beware

Ege: also validation is an issue
… format for json-pointer not quite right

McCool: really need a URL with a json-pointer as a fragment identifier

<Ege> https://w3c.github.io/wot-thing-description/#objectschema

McCool: perhaps can use a pattern like "{url} # json-pointer"

Sebastian: hard to understand

McCool: think we just need an informative paragraph explaining how it works

Sebastian: ok, added some notes to the PR

<sebastian> https://github.com/w3c/wot-thing-description/issues?q=is%3Aissue+is%3Aopen+label%3A%22PR+needed%22


Minutes manually created (not a transcript), formatted by scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC).