W3C

– DRAFT –
WoT-WG - TD-TF

03 November 2021

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Fady_Salama, Kaz_Ashimura, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Sebastian
Scribe
Ege, kaz

Meeting minutes

Minutes Review

<kaz> Oct-20

Sebastian: (goes through the minutes)

Sebastian: SSML recomendation 1.1 do they say backwards compatible?

Sebastian: XML also uses the old namespace (between 1.0 and 1.1)

Sebastian: any objections?

F2F Minutes Review

<kaz> Oct-28

Sebastian: manu sporny recommended to go with a new namespace

Cristiano: we are constraining the validation to validate the string in the context

Cristiano: context points to terms you can use. if 1.1 context just extends 1.0 it is ok?

Cristiano: is it ok to check for the exact url?

Sebastian: you are right, from json-ld perspective it is fine
… but a json processor would have problems

<Zakim> kaz, you wanted to suggest we discuss the detail AFTER the minutes review

Sebastian: any objections to make the minutes public?

<kaz> (none; approved)

TD Versioning

<kaz> TD spec Abstract section

Sebastian: maybe we can add information on how to convert 1.1 to 1.0

Ege: we can say 1.1 can process 1.0

McCool: that would be forward compatibility

Cristiano: we should do this carefully and stick to it in the next versions as well

Ege: we can define that validation is not mandatory

Cristiano: is it not mandatory?

Ege: it is not I think. So we can say that the backwards compatible does not mean validating new documents

Sebastian: we can say that for the new features, you have to update your software

<kaz> JSON-LD 1.1

Ege: but in conventional software, you don't have to update the code that uses a library if that library gets a minor version update

<kaz> JSON-LD 1.1 Processing Algorithms and API

Kaz: json-ld also had problems with versioning so we can look at their specs. We should think about what want to do for "compatibility" between TD 1.0 and TD 1.1 first, and then think about what kind of versioning mechanism is required for that purpose.

Kaz: I'm not suggesting we also generate a separate spec for TD 1.1 processing, though.

Sebastian: michael koster, how does sdf handle this?

mk: for new features, you need to update the document and the processor

mk: if you realized them, you can ignore them. called softbreaking

Cristiano: I think we are getting somewhere

<McCool> (sorry, I have to go...)

Cristiano: we do not change, e.g. title from string to object

Sebastian: adding profile keyword would mean that there is another behavior but that is not breaking

Daniel: we should be jsonld 1.1 compliant (I am not sure if I understood)

<cris> +1

Ege: maybe we can say that we add new terms, do not change the structure of the old terms but add new values. This means that if a TD parser was iterating through a key's values, it will not fail but it will meet new values.
… so for example, op will be an array and can be iterated through like an array but will have new values like `subscribeallevents`
… maybe @context needs some special note

Sebastian: any objections?

Kaz: we should change the namespace maybe

Kaz: don't object to the summary but as already mentioned during the DID joint call on Oct-28, maybe https://www.w3.org/2022/wot/td/v11 might make sense. also would suggest we quickly ask the JSON-LD 1.1 Editors for advice again.

Action: kaz to ask the JSON-LD guys for advice again

TD Roadmap

<kaz> wot PR 1000

Sebastian: (goes through the plan)

[[

0. Clarify which normative features in the TD 1.1, Architecture and Profile should be covered by mid-Nov

1. Roll back TD spec to 1.1 (1.0 compatible) features by Nov 30

2. Normative features freeze TD 1.1 & Architecture spec by Dec 15

3. Get wide review including TAG, Accessibilty, Privacy, Security, and Internationalization to review TD 1.1 draft

4. Normative features freeze Discovery spec by Dec 15

5. Feature freeze Profile spec by Jan 31

6. Testfest in mid-Feb

7. CR transition in mid-March

8. PR transition in mid-April

9. REC transition before end of extended charter end of July

]]

Sebastian: any comments?
… need to defer some of the features for TD 2.0
… normative features for TD 1.1 to be frozen by Dec 15

PRs

PR 1205

WIP: Fix issues in TM schema generation script #1205

Sebastian: (goes through the changes)
… would recommend we merge this PR

Kaz: one problem due to Ege's review

Ege: reverted

Sebastian: and merged the PR 1205

PR 1207

<sebastia_> Updates for TM Chapter #1207

Sebastian: moved the content to the Architecture spec

Preview of "10. Thing Model"

Ege: regular expression based on ECMAScript

Kaz: do we have sufficient implementations for TM features in general?

Sebastian: we already have multiple implementations

Kaz: in that case, we need to update the test results

Ege: right

preview of "10.4 Derivation to Thing Description Instances"

Sebastian: two options for TD generation
… single derivation or multiple derivation

Ege: we can merge this PR 1207 and add fixes later

Kaz: note that there is a typo
… "Please not that ..." should be "Please note that ..."

Sebastian: have issue with direct change within the PR
… because we need to regenerate the index.html based on the index.template.html
… let's fix the typo as well later
… (merges PR 1207)

Issue 1265 to fix the remaining issues

PR 1254

fixes #1247 #1254|

Sebastian: fixed Issue 1247

Allowing type to be an array #1247

Ege: should update the text for PR 1254

Sebastian: (records a comment we should not merge this for TD 1.1)

Sebastian's comment

PR 1257

Add op values description table #1257

Sebastian: (merged)

[adjourned]

Summary of action items

  1. kaz to ask the JSON-LD guys for advice again
Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).