Meeting minutes
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://
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://
RESOLUTION: publish, after a two-week review starting today 25 May 2022 and a resolution in the main call, branch cr-wd-update (https://
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]