W3C

- DRAFT -

WoT-WG - TD-TF

29 Jul 2020

Agenda

Attendees

Present
Kaz_Ashimura, Cristiano_Aguzzi, Daniel_Peintner, Michael_McCool, Sebastian_Kaebisch, Taki_Kamiya, Ege_Korkan, Tomoaki_Mizushima
Regrets
Chair
Sebastian
Scribe
McCool

Contents


<kaz> scribenick: McCool

Review minutes for July 15 and July 22

https://www.w3.org/2020/07/15-wot-td-minutes.html

https://www.w3.org/2020/07/22-wot-td-minutes.html

no objections to publish July 15 minutes

no objections to publish July 22 minutes

Vacation time and meeting schedule

sebastian not available 19/8, 26/8, and 3/9

Sebastian: will Taki be available?

Taki: yes, I will be available

Sebastian: it would be ok to have a break, too

Taki: in that case, let's cancel the 19th and maybe the 26th

Sebastian: definitely cancel 19; taki can decide and announce in the main call
... based on open issues

McCool: I will also record cancellations in main wiki page

https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Cancellations

Release dates

for TD1.1 https://github.com/w3c/wot-thing-description/labels/FPWD%201.1

json schema issue has been fixed - https://github.com/w3c/wot-thing-description/pull/896

<Ege> brb in 2 mins

Sebastian: have asked Daniel to fix render script
... to generate based on ontology files

McCool: other PRs also need to know how render works, eg in the ontology file or in the template

Sebastian: we also want the rendered diagrams based on the ontology

Cristiano: we also talked about contentType, etc.
... where will these changes go?

Sebastian: actually I forgot where this was supposed to go; I will update the issue and deal with this as well in the PR

<sebastian> https://github.com/w3c/wot-thing-description/issues/912

look at oauth2 pr

https://github.com/w3c/wot-thing-description/pull/927

issue with using an ontology (formal vocab) for flow names

<trackbot> Sorry, but no Tracker is associated with this channel.

would want to do this in a backward compatible way, and allow external vocab to define extensions

eg it needs to be an open enumeration, not closed

Sebastian: let's discuss under the PR

next, issue 937

https://github.com/w3c/wot-thing-description/pull/937

seems there is an issue in the context files

Sebastian: some redundancy
... in particular, an @id under security seems wrong

McCool: certainly I may have made an error here

Sebastian: ok, I will check it
... also moving TDT to main section https://github.com/w3c/wot-thing-description/pull/938
... these are all the PRs that would go into TD 1.1

McCool: so this is just a move, not a redefinition?
... I do think we should loosen the definition a little
... for example, it should not be mandatory that security is omitted
... maybe we should allow URI templates in forms, etc

Issue https://github.com/w3c/wot-thing-description/issues/932

how to version scripting API separately from TD versioning

Cristiano: also TD and scripting versions are coupled at present
... need to know which version of TD a version of the scripting API works with
... how do we deal with "semantic" versioning when we also have "dated" URIs for context files?

Sebastian: kaz, do you have any experience with how this is handled?

Kaz: we can look into JS and HTML
... but the assumption there is that everything is backward compatible

Daniel: example is XML schema, version 1.1 still uses the same namespace
... so looking at the namespace can't be used to determine the version

McCool: I personally would like to see a scheme like .../v1 referring to latest v1, v1/0 and v1/1 referring to specific versions
... unfortunately the date in the URL messes that scheme up

Sebastian: we should ask the JSON-LD group about this topic

<kaz> <script type="application/javascript;version=x.x">

Kaz: if needed we can use something like the HTML version tag, e.g. using extended context, or adding specific tag

McCool: assume we are focusing on TD versioning for now

Kaz: good JSON-LD joint meeting topic

Sebastian: agree

McCool: we should reach out to them and schedule that

Issue updates from wot

Sebastian: thanks ege for moving issues over from the old wot repo
... there are some interesting ones

https://github.com/w3c/wot-thing-description/issues/936 using links for UIs, IDE

Sebastian: also relates to Schema, but we have also introduced title and descriptiong
... but an open question is how to provide icons, etc.
... cannot be solved by linking, since links are only at top level, not at the interaction level
... maybe it can be dealt with using semantic annotations

Sebastian: please share ideas on issue

Ege: I also think semantic annotations would be the easiest way to do this

<Ege> https://schema.org/logo

McCool: I think for "generic" icons associating it with a semantic tag might be feasible, but for branded icons it is tricker
... logo thing seems more like an extension than an annotation
... if it's a common extension, maybe it should be in the main spec
... in HTML it makes sense as an annotation since you can annotate an existing image tag with microdata

issue https://github.com/w3c/wot-thing-description/issues/935

McCool: class field to be able to modify several properties at once

Sebastian: we may also be handling this in different ways now

McCool: I think this is more of a scripting API issue if it is about manipulating multiple Things at once
... eg the result of a query on a particular annotation

<dape> https://github.com/w3c/wot-scripting-api/issues/204

Daniel: this does not seem like it should be in the core spec of scripting though

McCool: I agree, it can be implemented using other features we are already working on, in particular semantic annotations and directories queries that return a set of results
... but we might have to consider some tweaks to make it possible to submit queries to directories without revealing the URL of directories (for privacy reasons, eg. to avoid fingerprinting...)

Issue https://github.com/w3c/wot-thing-description/issues/934

<inserted> related issue on wot repo

Sebastian: my reading is that this example is addressed with our current spec
... except for global definitions of types
... example uses SSE defined in a "protocol" field
... for example; but this specific case we have subprotocols now

<sebastian> https://github.com/w3c/wot-thing-description/issues/307

Sebastian: then there is the use of $ref etc for definitions
... there are points on our roadmap that will address the compound values

<inserted> https://github.com/w3c/wot-thing-description/issues/934

Daniel: but not sure about streams; there is another open issue on streams I believe

Sebastian: let's keep it open, and discuss

Modbus binding

Ege: looked into in detail

<sebastian> https://github.com/w3c/wot-binding-templates/pull/98

Ege: is missing concept of default modbus binding
... e.g. is read property reading a bit a word?
... also, do vocabulary files need an "editor" at the top?
... respec gives me a warning if there is no editor

Cristiano: also the examples still need to be updated; the uppercase values need to be camel-case

Sebastian: would check that the terms use correspond to normal modbus terms

Cristiano: may also have to update node-wot implementations, may not have used the exact same terms

Kaz: I thought there are two resources here, (1) machine-readable vocabulary definition and (2) human-readable document describes that. If we want to publish the human-readable document as a W3C Note, then we DO need an editor
... applies to human-readable documents

Cristiano: about length and byte length, for node-wot, length is defined in content type

McCool: I am also wondering about extensions to data schema for bit length

Ege: better to distinguish data schema from protocol information

Cristiano: problem is that if returns something like json, then it is redundant to have the length
... but if the content type is an octet stream, we should include the length in the content type

Sebastian: seems like it needs more deliberation; have taken notes in the issue
... we will watch for his replies
... author only worked loosely with Ege

Kaz: maybe this is overkill, but do we want to worry about "livestreams" where the end is not known?
... possibly related to media discussion

Cristiano: not applicable to MODBUS
... might apply to other protocols however, e.g. media

McCool: assume in the case of livestream we could use a content type without a length
... ends when socket is closed

Sebastian: ok, done, move to adjourn

<kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/07/31 10:37:51 $