<taki> scribeNick: taki
<inserted> Dec-9
Sebastian going through 2020-12-09 minutes...
Sebastian: We will be making
prototypes for bindings, to make separate documents for various
protocols.
... #1007. We decided to keep it as it is.
... #800. We forgot to include those options before.
... Minutes were approved.
Sebastian: We will consider them
in new versions. They may have impact on compatibility.
... I plan to work more on this list. Please take a look at the
current list, and make comments.
Sebastian: There was a meeting
with IETF SDF group this week.
... We did not have deep discussion. We want to dicuss on SDF
and TD.
... We can consider OneDM as TD's model.
... I created an issue #903 a back while.
... Can Koster give us update on the latest discussion?
Koster: Yes. I can go over use
cases, refreshing everyone. IoT data models, Zigbee, TD, IoT
Schema, Bluetooth, OMA, OCF, etc. We came up with common
model.
... Common goals became clear among them including Mashup. TD
and iotschema were candidates.
... There was a language requirements. RDF was considered but
not selected.
... Reusability. Define once and use many times.
... It cannot be tied to specific data schema and
representation.
... Realign with existing 13 practices.
... event/action/properties classes are common across.
... they seem to map well everywhere.
... You can bind them to protocols.
... "Mapping files" can specify additional constraints for
protocols.
... As with TD, SDF is declarative.
... with semantic anchors (JSON pointer)
... SDF has a way to make consistent URI.
... SDF has required/optional events.
... similar to JSON schema, but be brought to higher
level.
... We added enumeration in version 1.1
Sebastian: Mapping file. Does it have its own format?
Koster: I have an example. it is
key-value pair using JSON pointer. each entry adds/modify
existing entry.
... You can add Zigbee constant 8 in mapping file, for
example.
... We can consider inline mapping file as well in the
future.
... Mapping files can contain hints such as the way to map
properties.
... That way you can separate general part from specific
part.
<Zakim> dape, you wanted to expressiveness
Daniel: Expressiveness difference. SDF can contain several things. SDF can result in several multiple TDs. Is this on purpose?
Koster: SDF has a few more
classes that are not present in TD. Things that have multiple
capability. We found them from existing models.
... TD does not have Object. Light valves, can have
capabilities.
... TD can use annotations for this.
... We decided to have Objects in SDF instead.
... Thing could be a composition of other Things in TD.
... Zigbee light valve using TD, we will face this issue.
Daniel: it makes sense.
Koster: It is going to be an interesting exercise to see if there are issues such as conflicts.
Sebastian: We also have linking concepts.
Koster: Yes. In LwM2M, we use links for structure.
Kaz: How to deal with externally defined vocabularies and how to refer to them?
Koster: SDF allows to use
namespace feature. Uri-prefix works.
... We need to make an external server to make dereferences
into a single file.
Kaz: In that case, intermediate format can be quite similar to TD.
Koster: Light switch model. You can get SDF for that. And then convert to TD with annotation.
Kaz: Thank you.
Koster: SDF is very much like
iotschema. We can convert SDF to iotschema very easily.
... iotschema can refer back to SDF with annotations.
... How to make a forward reference from SDF to iotschema is an
issue.
Sebastian: I will come back in 5 minutes or so.
Koster: SDF object file can be a
single a model. They can be composed into TD.
... SDF can be used as Semantic proxy between for example, OCF
and TD.
Sebastian: We have abstract definition of SDF, translating to TD with protocol binding. We need to clarify.
Sebastian will come back shortly...
Kaz: We can take a short break...
Taki: "We need to use some examples to translate abstract definition of SDF into Thing Model, to obtain TD with protocol binding. "
Daniel: I saw examples. The term changed?
Koster: Yes. SDF objects with optionality can also be looked at.
Sebastian is back...
Koster: I proposed to create two Zigbee/Dotdot examples with optionality.
<kaz> wot-thing-description Issue 903
Sebastian: We can also use the workflow, and explain it. We can refer to SDF definition from examples.
Koster: I will provide examples including On/Off light valve example.
Sebastian: I would like to assign this task to Koster.
Koster: We can consider a feature to import SDF into TD editor.
Sebastian: Plugin feature can be considered in the editor.
Koster: We can test mapping files
in that effort.
... We can make a standard/customized mapping files based on a
single SDF.
Sebastian: I plan to provide a chapter on generation of TD from Thing Model with examples including a SDF example.
Sebastian: Information on implementations of TD producers.
<kaz> Issue 774
Sebastian: Similar to server term in HTTP.
Sebastian shows an example "Apache/1.3.27 (Unix)..."
Sebastian: In the form of
tdProducer: mode-wot/0.7.1 in TD.
... A use case. for debugging purpose.
Koster: can be used forensic
analysis.
... I do not see a strong need for this.
Kaz: Not sure if it would really
make sense in TD context.
... We should be careful.
<kaz> scribenick: kaz
Koster: there could be security issues too
Sebastian: right
... (adds comments to issue 774)
... we should not add this feature now
... maybe for 2.0 version
Kaz: possibly
Sebastian: (assign @mmccool for the possible security concerns)
Sebastian: think this is already solved
Daniel: yeah, it's very old
Sebastian: (goes through the issue)
Koster: prefer not using this parallel processing
Kaz: +1
Sebastian: (shows example 32)
Sebastian: we could allow this simpler expression:
"forms": [{
"op": ["readproperty", "writeproperty"],
"href": "https://mylamp.example.com/status"
}]
Sebastian: to be converted to:
"forms": [{
"op": "readproperty",
"href": "https://mylamp.example.com/status",
"htv:methodName": "GET"
},
{
"op": "writeproperty",
"href": "https://mylamp.example.com/status",
"htv:methodName": "PUT"
}]
Kaz: technically, human beings
can convert that based on our own knowledge on HTTP
methods
... however, it would require all the TD processors to know
about any kind of protocol methods
Sebastian: right
... (adds comments to Issue 712)
... there should be also procedure description how the
transformation to the default representation
... I can provide a PR for that
Sebastian: array for response in the
From class
... changing it to array of responses
... Farshid gave a comment
Kaz: do we have any concrete use
case for this?
... and did we check that during our Plugfests?
Sebastian: don't think so
... possible use case might be having multiple content
types
Kaz: sounds like a use case of fallback with some errors
Koster: possibly switching servers based on those errors
Sebastian: might be useful but would
break backward compatibility...
... so wondering how this need is urgent
... possibly related to discovery too
... having multiple entries for "response"
Kaz: yeah
... if the possible use case has urgent importance from some
business viewpoint, we should think about this
... but if not, can be deferred
Sebastian: (adds comments)
... we'll ha a backward compatibility issues
... should talk with the Discovery TF to clarify the need
Sebastian: would close the call now
:)
... thanks a lot for your hard work and great
contributions!
Kaz: the next TD call will be on 13 January 2021. right?
Sebastian: exactly
[adjourned]