<inserted> scribenick: sebastian
need some short abstract about the task forces
including the task forces leaders
<kaz> Welcome page
McCool: we should use a template for each section
<kaz> TD-TF
<kaz> Ege's issue 85
McCool: there is an issue from Ege that gives an overview about the current content of all the task force wiki pages
McCool: we should agree on a
template
... who can help here to create a template?
Ege can provide a template.
Ege: Which points should be covered?
McCool: Main page has the most contents and covers many points
Ege: Discovery can be also used to create template
Kaz: Daniel developed an CSS file for the webpage. Shall we use this for the template as well?
McCool: Prefer the wiki style
... we should keep the wiki structure
Kaz: we should have the detail
structure of the MD files for task forces
... should discuss this in the marketing call
Ege: https://w3c.github.io/wot-marketing/activities/tf-td/
is html file which will be not changed
... only the content of the wiki page will changed like the
agenda
Kaz: I'm OK with writing the details of each TF's activity using, but the discussion on the structure of the whole pages should be done during the marketing call
Lagally: +1 that the structure should be agreed during marketing call
Ege will prepare a proposal for the next marketing call
next week marketing call is canceled
so, will discuss this one week after
Please other TF should also think about the content
Lagally: Yes, should be not that complicated to provide some sentences about the scope of the TF
<Ege> https://github.com/w3c/wot-marketing/pull/99/files
Kaz: we should also provide the last minute changes in the index.html in github master
<kaz> Kaz's editorial updates for publication (Member-only)
There were some discussion about TD 2.0 roadmap
McCool: we should provide a CR 1.1 version in March to be on time
<kaz> Milestones calculator, fyi
McCool: it's quite tight in
schedule
... different option such as work in parallel on TD 2.0 and TD
1.1
I think this is not a good idea
Kaz: if we can not finish or start the work on TD 2.0 we need to get rechartered for ver 2.0 and some more possible additional deliverables
<kaz> scribenick: kaz
Kaz: wondering about the actual "roadmap" for 2.0 version
McCool: let's get a poll about deferring
the 2.0 version to the next Charter
... need to discuss during the main call as well, though
<McCool> summary it seems we are leaning towards deferring 2.0 to the next charter and focusing on 1.1 in this charter
Sebastian: provided an example
... (put the example TD to edi{TD}or)
Sebastian's comment including the example
McCool: need a list of placeholders?
(like "URL_PLACEHOLDER, ID_PLACEHOLDER", ...)
Lagally: also versioning should be mandatory
McCool: yes, it should be mandatory
... we should put version identifier in the id and "version"
metadata
Ege: how to handle major/minor/patch versions?
McCool: several different views
possibly
... TD is instance of model
... if we have a new version of TD, what would happen?
Ege: depending on the use cases
... some people might think semantic versioning wouldn't work for
API versioning
<Ege> https://w3c.github.io/wot-thing-description/#example-31
Ege: version for instance and version for modl
Sebastian: (loos into Issue 1000)
... example of Eclipse Vorto model
<Ege> https://github.com/w3c/wot-thing-description/issues/947
Sebastian: would it make sense to add "model" term to "version"?
McCool: another possibility is that Thing Model's version number simply refers to the version of the Thing Model specification
Lagally: would be confusing
McCool: that's true
Sebastian: what should we do then?
McCool: for Thing Model, should only have
"model"
... without link
Sebastian: ok
"version" : {"model" : "1.0.0"},
Sebastian: let's quickly do that
... (reusing the "version" container, skip `instance` nd introduce
a new term `model`)
... (adds an updated example to Issue 1000)
McCool: we could think about DID here
version definition for the model:
"version" : {"model" : "1.0.0" },
version definition for the instance:
"version" : {"instance": "1.0.0",
"model" : "1.0.0" },
"links" : [{
"rel" : "instanceOf",
"href" : "<address of the TM model>"
}],
table within section "5.4 Default Value Definitions"
Kaz: note there is "5.4" twice within the section title
Sebastian: right
... (creates an issue on that)
... regarding the issue 1003 itself, would it make sense to have
more detailed description on op?
(no objections)
Sebastian: Ege, can you create a PR for this?
Ege: ok
Sebastian: there is actually a section for
Multilanguage (https://www.w3.org/TR/wot-thing-description11/#multilanguage)
... (adds a comment)
Sebastian: the IP address where the TD comes from
McCool: model is meant to be more
abstract
... directory entry for discovery needed
Ege: IP address possibly changes based on the environment for mobile usage, etc.
McCool: maybe you could describe the
device itself
... would suggest we write up a use case for that
Kaz: agree we should generate a use
case description about this
... related to how to deal with session lifecycle
McCool: two possible issues
... no IP address
... and change of IP address
Kaz: no IP address specification for
Thing Model may imply dynamic address assignment
... there are several possible settings
Sebastian: some of the combinations should
be prohibited
... e.g., both readOnly and writeOnly as "true"
McCool: maybe JSONSchema guys know how to avoid it
Koster: should be compatible with oneDM
McCool: readable/writable would be clearer
Sebastian: (adds Henry Andrews for JSON Schema and Mchael Koster for SDF)
[adjourned]