Meeting minutes
agenda review
<kaz> Agenda for today
Sebastian: focus on review of PRs and prepare for final document review
McCool: issue #940, question around signing
minutes review from last meeting
<kaz> Apr-28
Sebastian: walking through the PRs that we reviewed last week
Sebastian: we decided to allow as much of JSON schema as we can, and include the missing terms
McCool: there were also some arbitrary extension points that we discussed
… we should not allow extensions because it prevents good checking for typos
Sebastian: discussion on selection where multiple forms are present
… discussion on URI variables
… PR for tmRequired and tmRef
… there will be a new namespace and prefix convention for TM
… they will be tm:required and tm:ref using the new namspace
Sebastian: does the SDF use of required apply to anything or just interactions?
Koster: sdfRequired can point to any JSON node, including interactions and sdfChoice (enum) elements
Sebastian: minutes themselves have been approved
Publication
Sebastian: call for review after this TD call, and we're planning to publish the updated TD draft May 19
Sebastian: we can add a sentence to clarify the use of tm:required
PR reviews
PR 937
<kaz> PR 937 - WIP: swap securtiy and securityDefinition in context file
Sebastian: #937
PR 943
<kaz> PR 943 - WIP: Add proof and proofChain sections
Sebastian: #943
McCool: we are rebasing the PR so should close this one
McCool: the new PR will be based on issue #940
PR 1085
<kaz> PR 1085 - WIP: Add Validation Section
Sebastian: Validation section
McCool: could merge but the tagging is not done yet
Sebastian: agree to merge
… maybe we could think more about the naming of the categories
McCool: we could change it to minimum + basic
McCool: will add an editor note about the tagging and make the name change
PR 1120 - validation for icon links
<kaz> PR 1120
Cristiano: it validates the size metadata
Cristiano: adds a validation rule when sizes is present
PR 1121 - introduce profile term
<kaz> PR 1121
Sebastian: optional term for indicating the profile mechanism, URI pointing to a wot profile
Ege: it could be an array with "and" validation of all profiles
… the definition should have a statement about how multiple profiles are applied
… a consumer may only need to support one of the offered profiles
McCool: a producer may support more than one profile at the same time
… need to add this explanation to the profile specification
Sebastian: there could be a question of which form to consume when there are multiple choices in forms
Koster: the profile may inform that, do we need to provide additional guidance in the spec?
McCool: probably can leave it up to the consumer
dape: why doesn't the shape for interaction affordances have an order number?
Victor: it is intended to allow any or none (?)
PR 937 (revisited)
<kaz> PR 937 - WIP: swap securtiy and securityDefinition in context file
Sebastian: why does securityDefinitions not appear in the ontology?
McCool: it may be a mistake in the file
McCool: it could be incorrectly generated
Victor: securityDefinitions is just a container, like definitions in JSON schemas
… it's only a reference
McCool: there is confusion between the information model and the serialization
<victor> https://
McCool: when converted to RDF, they are all flattened to the same RDF property
McCool: for canonicalization, we need to preserve all of the nodes in the original document
… it's probaby easier to pass them through round trip rather than regenerate
Victor: should the information model then be changed?
McCool: there is the same issue with named dataschemas in additional responses
Victor: what changes need to be made?
McCool: start with the rendering
McCool: we may want to change security to allow objects for names schemes
Victor: it would align better with RDF
Sebastian: this isn't critical for the specification
McCool: it blocks progress due to the dataschema issue
Victor: can provide a TD normalization script
McCool: sounds similar to canonicalization
McCool: we can discuss offline and track on the issue tracker
Sebastian: should we involve JSON-LD people?
Sebastian: it seems related to #1077
PR 1104 - Data schema issues
<kaz> PR 1104 - Address multiple DataSchema issues
Sebastian: adds a new term "default"
Sebastian: adds a note on the "format" term being removed in future versions
Ege: it has been replaced in JSON schema with a new vocabulary feature which we could continue to use
<McCool> @dape that's what I did, not rendering. Trying "section" (that is what is done in architecture)
Sebastian: also adds "pattern" term for constraints using regex
<Ege> https://
McCool: use of regex should exclude script execution
McCool: the JSON schema subset is reasonable
McCool: maybe we could just use the regex subset definition text on the JSON schema website
<McCool> mm: probably the solution is to copy that text into our spec, but we need to ask for permission to do so
Sebastian: merge conflict...
… merged
PR 1085 - Add Validation
<kaz> PR 1085
McCool: added the editors note for no tags and changed the validation category names
Sebastian: ready to merge?
PR 1113 tm:required and tm:ref
<kaz> PR 1113
Ege: implementation of this PR is in the script that generates the files
PR 1122 - terminology
<kaz> PR 1122
Sebastian: merge conflict resolved
… merged
PR 1123 - tm namespace
<kaz> PR 1123
Sebastian: new tm namespace and ontology
… initially we have only three concepts but more will be added
… reviewing changes in the rendered document
Sebastian: added a rule that extended definitions must be valid wrt the base definition
… merged
PR 1124 - canonicalization
<kaz> PR 1124
Sebastian: adds some clarifications
McCool: addressed some issues and bugs
Sebastian: merge conflicts, mm will fix and merge
Working draft review
Sebastian: take the next 2 weeks to review this document for working draft publication
Sebastian: still some remaining issues
McCool: we are working on a signing section and have some proposals
Issue 940
McCool: will make a PR that we can comment on
Sebastian: any other issues to look at?
<kaz> (none)
<kaz> [adjourned]