– DRAFT –
WoT-WG - TD-TF

Minutes Review

<kaz> May-18

Sebastian: (after presenting today's agenda, starts reviewing the minutes of the meeting)
… we started with a minutes review and the wide review
… talked about security related issues, e.g. IDs
… then we checked some PRs
… Michael Lagally pointed out that PRs often contain unrelated changes, which is caused by the render script
… this only affects the rendered version of the document, though
… then we moved on to other PRs
… JSON schema and ReSpec fixes were discussed
… also @context requirements for Thing Models
… a PR regarding an updated testing template was postponed to this meeting
… as well as a PR regarding text direction
… another PR regarding double encoding in tm:ref was merged
… that is it, many PR were discussed
… any comments?

There are no comments

Sebastian: Seems not the case, then please bring the minutes to the public, Kaz.

PRs

Sebastian: Let's start with the easy ones

PR #1507

<kaz> PR 1507 - Beautify infromation model drawings

Sebastian: This PR improves our diagrams in the document
… the SVG files currently present in the document are auto-generated
… good proof that the ontologies are well-defined, however, they are not very suitable for being displayed in a specification
… the PR improves the visual quality, however, they are manually generated, the boxes and lines are adjusted by hand
… please don't be confused as the diff compares the new diagrams to the ones from the 1.0 version
… I noticed, that there is something I need to add to the render script, which is not adjusted yet
… otherwise the new figures would be overridden again

Daniel: Aren't only the SVGs automatically generated but not the PNGs?
… rerendering the SVGs then does not make a difference if PNGs are used in the document

Sebastian: You are right, rerendering the SVGs does slow down the rendering process, though
… but the script does not need to be updated for this PR
… any comments?

There are none

Sebastian: Then I would proceed to merging

Daniel: Just a quick question: You used the SVGs as a starting point and then adjusted them?

Sebastian: Exactly
… okay, then let's merge this one

PR is merged

Sebastian: In the review phase, the alignment of the diagrams with the tables is something that needs to be ensured

PR #1506

<kaz> PR 1506 - Note about the id derivation from TM

Sebastian: This is the next easy PR
… it is about the Thing Model section
… it provides a new guideline for the replacement of a TM's ID value, which should now use a placeholder
… this can then be used for the TD generation process

McCool: This is new, right?

Sebastian: This is new, coming from the discussion with Cristiano
… previously, it was not stated what to do with the ID in a Thing Model

McCool: I think we can agree that the ID in a TM is only for the TM, not for the TD
… I think the process should demand that the old ID should be deleted and a new one should be generated instead
… introducing a template just causes potential trouble

Sebastian: The placeholder can be used to enforce generating a new ID
… prescribing an ID in a TM would imply that only one TD can be generated from the TM

McCool: Using this feature to embed metadata in the ID is an antipattern
… there is an assertion in the Security and Privacy Considerations to not embed metadata in IDs
… IDs are not as well protected as the TD itself
… privacy-critical IDs should be modelled as a property
… I am okay with this merging this PR, but I want to understand the reasoning behind the new assertion

Sebastian: This is just an example, but we can remove the assertion

McCool: We can use a placeholder for the ID, but it would be better to require the use of something like UUIDv4

Sebastian: I can make changes to the PR

Cristiano: I am okay with the changes, the PR was more about giving an example for the use of IDs in templates (?)

McCool: Lot's of people embed IDs in URLs, but this is more of a Discovery issue
… please add an assertion that people should not embed metadata in IDs

Cristiano: How about adding another field tm:id?

McCool: Yeah, there is a problem with the overlap of TD IDs with RDF @id
… not requiring this to change, but it is something that needs to be considered

The PR is updated in accordance with the discussion, using a {{RANDOM_ID_PATTERN}} in the id field

Sebastian: Any more comments or objections?

There none, PR is merged

PR #1505

<kaz> PR 1505 - Updated Implementation Report and Results Files - May 2022

Sebastian: This PR is about the updated Implementation report

McCool: There were a lot of annoying issues with the csv files
… most of them have been fixed, the manual assertions need to be reviewed, though
… there are a lot of new security-related assertions
… many fields have 0 entries right now, but most of the assertions can be simply answered with "yes"
… we have a lot of manual assertions that need to be addressed at the next test fest

Sebastian: Let's merge this for now, after the next plugfest in two weeks we will have a new version

PR is merged

PR #1501

<kaz> PR 1501 - WIP: Add at-risk hints

Sebastian: This PR is an overview of the assertions that do not have a test report yet
… for every feature with missing implementations, the PR adds an at-risk label
… I didn't include the label for every feature

McCool: Did you also edit the csv files?

Sebastian: I added the labels directly to the document, not edited any csv files

McCool: Before, I generated the at-risk labels from csv files, adjusting the CSS
… I created a testingatrisk.css file before
… I need to check my script again

Sebastian: There are a number of features which are low-hanging fruit, this should probably not be included

McCool: The script cannot distinguish these, works only on the basis of test results
… people should provide tests for these
… I will double-check my script if it still works and will create a new PR for that
… we can then discuss it next time

McCool: There are also sections, which are being marked as at-risk. These need to labelled manually

Sebastian: I'll mark my PR as a draft, for now. Let's move on to the next PR

PR #1498

PR 1498 - Update template.csv for testing

Ege: Did not have time to work on the PR

McCool: There might be conflicts if we work on the same file
… my suggestion would be to use a different file name, e.g. assertions.csv
… there differences in the columns

Ege: I actually use your script, but it is probably an old one

McCool: If you are only interested in assertions, there is script by Tomoaki-San(?), which you can use

PR #1499

PR 1499 - Reference to string-specific directional information

<kaz> s/Tomoaki-san(?)/Toumura-san/

Sebastian: This is a PR that deals with an issue raised by the i18n task force
… a problem here is that the new reference is a group note, causing problems if we include in an assertion
… proposal: Keep the old process, but add a reference in a note

<McCool_> (I can take over minutes after this issue is concluded)

Kaz: I don't know if this PR actually resolves Addison's point, it needs further review

Sebastian: It is about a paragraph about text-direction
… replacing it with the referenced guideline document
… the problem is, that all sentences here are assertions

Kaz: We should think about which description should be added to the specification to clarify the expected features
… and then extract the RFC keywords, before testing the assertions
… we should check if the text actually contains what we want to express in the TD specification

McCool: Problem is, these concerns are raised by the i18n group
… the string meta-data document, which is supposed to be cited, is quite vague in my opinion, though
… the core issue is about text-rendering, however
… not about encoding information
… citing the string-meta document might be more future-proof than pre-scribing a process for determining text-direction ourselves
… the main problem is that string-meta is a group note

Kaz: It is not a problem from the W3C standpoint, so it could be included
… if the content is okay from our point of view, then citing the document will make our lives easier

McCool: It also eliminates a lot of test cases

Sebastian: conclusion, let's merge, and this resolves all internationalization issues
… and also done with all important PRs needed for next version, WD or CR candidate

issues

Sebastian: let's look at issues see if there is anything important

issue #1513

<kaz> Issue 1513 - Update JSON Schema validation reference

Ege: about the right JSON version
… we thought we were at the wrong version, but we are ok
… so can close this issue, nothing has to be done
… see Jan's comment
… basically we are using the Draft 7, and want to stick with that version
… as this is the most commonly supported version

Sebastian: (adds notes to issue)

Sebastian: closes issue

Sebastian: will Lagally have concerns?

McCool: we discussed this in profiles call, agreed to just be consistent with TD
… so not a worry

issue #1508

<kaz> Issue 1508 - item vs tm:submodel in TMs

Jan: items vs. submodel
… what to do with collections, items, etc.

Sebastian: thought I had an example about this

Jan: is an example for replacing a submodel with item links
… was wondering if you could also use item links directly
… suppose I want to generalize a TD by converting to a submodel, would be easier if could just use item links in TMs

McCool: so is the problem that going from TD->TM is difficult?

Jan: partially; two different composition mechanisms
… TD uses item links, TMs use submodel

McCool: do these mean different things semantically?

Sebastian: in TD is only metadata, not really needed; in TM is required functionally

Sebastian: but it seems you would also like to describe the relationship

Jan: right

McCool: are there any item links in TDs that do not map to submodels in TMs?

Sebastian: interesting use case, want to understand the scenario

Cristiano: we introduced submodel but really did not clarify how it is different from item

McCool: if it is different, we should say how; if not, then should get rid of separate name

Cristiano: but I do feel they are different, but it is subtle

McCool: I feel someone needs to write some definitions to clarify what each term means

Sebastian: Jan, I suggest you try to clarify this in the issue, but we probably need to defer to the next major TD version

Jan: sure, it's just something I noticed that came up during conversion; but I will try to elaborate some use cases

Sebastian: (comments on issue; defers to TD 2.0)

issue #1510

<kaz> Issue 1510 - TD JSON Schema not backwards-compatible with v1

Sebastian: TD JSON not backward compatible with 1.0

Daniel: there is a strict context check; not allowed to have just 1.0 context
… but it means that 1.1 is not technically backward compatible

McCool: so should we use ben's suggestion of different code paths?
… or an "if"?

Daniel: discussed this with ege, conditional tests are difficult to implement in JSON Schema

Cristiano: well, if we do that, we do need to update some assertions

Sebastian: statement for use of @context

<kaz> i|TD JON not b|Issue 1510 - TD JSON Schema not backwards-compatible with v1|

Daniel: back to an implementation, have use v1.0
… upgrade to something that can handle v1.1, now old TDs fail

Daniel: would be ok if failing for 2.0, but 1.1 is supposed to be backward compatible

Ege: is also about issue about defn of backward compatibility
… we want a new consumer to read an old TD
… but not the other way around
… maybe we need an assertion that a 1.1 consumer can consume a TD 1.0

Ege: assertion about TD 1.0 should be changed a bit...
… need to be careful about consumers/producers

McCool: need a concrete assertion to look at

Sebastian: let's do it live, as a normative change this is not something we have a lot of time for

McCool: suggest just add an assertion saying TD 1.1 consumers must accept TD 1.0 inputs.

Ege: agree, can be very simple

Sebastian: (types in an assertion, various wordsmithing discussions...)

<cris__> +1

Sebastian: creating PR #1515

Daniel: does not completely solve problem... JSON schema needs to be updated

McCool: no, it's ok, assertion points at the old spec, and so old JSON schema

Ege: still think it will be confusing, people may still try to use the new schema to validate old TDs

McCool: I think that can be resolved with some informative text, etc

WD update decision

Sebastian: are we ready for a freeze, start a two-week review, publish a WD update for review
… if there are no major problems found in the next week, this can be the CR candidate

proposal: publish, after a two-week review starting today, branch X as a WD update

proposal: publish, after a two-week review starting today, branch cr-wd-update as a WD update

<sebastian_> cr-wd-update

proposal: publish, after a two-week review starting today 25 May 2022, branch cr-wd-update as a WD update

<sebastian_> https://github.com/w3c/wot-thing-description/tree/cr-wd-update

proposal: publish, after a two-week review starting today 25 May 2022 and a resolution in the main call, branch cr-wd-update as a WD update

proposal: publish, after a two-week review starting today 25 May 2022 and a resolution in the main call, branch cr-wd-update (https://github.com/w3c/wot-thing-description/tree/cr-wd-update) as a WD update

RESOLUTION: publish, after a two-week review starting today 25 May 2022 and a resolution in the main call, branch cr-wd-update (https://github.com/w3c/wot-thing-description/tree/cr-wd-update) as a WD update

McCool: suggest we discuss who does the prep work

McCool: about how long will it take?

Kaz: about 1 day of work

<kaz> guide

McCool: where is process documented?

Daniel: I can take a stab at it

Next meeting

Sebastian: also, for next week, no TD call due to Hannover Fair
… so next mtg will be June 8

McCool: pls update the wiki, I will update the calendar

Sebastian: adjourn, thanks for all your work, and have a good holiday

<kaz> [adjourned]