Meeting minutes
Minutes
<kaz> Nov-15
Ege: Already reviewed and sent to the mailinglist
Kaz: We also need to review the TPAC coordination call
<kaz> Nov-2 TD coordination call
Ege: We can also approve this one with a small change
TD Call slot
Ege: I sent an email and a doodle and received feedback
Ege: We'll use the new slots from the next year
<kaz> Doodle
Ege: I contacted people that shown interest to join the call in the future
Ege: The current slot is good for almost everybody
Luca: If it needs be it is fine for me as well
TD 1.1 Publication
Ege: Kaz already did a first pass using the Pubrules checker there aren't any errors but still need a change log section
Kaz: I can create a Transition Request for REC right after this update is applied.
<Ege> https://
Ege: <goes over the diff.html diff from Proposed REC>
Ege: is there anything more to add or amed?
Kaz: Did you edit index.html and then generate the other?
Ege: Yes
Kaz: note that I'll update the pubdate of Arch and Discovery within the TD spec as I mentioned during the main call.
Binding Templates
<Ege> ack k
BACnet
PR 318 - Draft: BACnet protocol binding improvements
Dogan: I fixed discrepancies between http and ttl
Dogan: I doublechecked BACnet and removed covPeriod since it cannot be influenced by the TD
<patch reviewed, comments noted in the PR>
ack
<kaz> Web of Things (WoT) BACnet Binding Template - 4.1 URI Syntax
Dogan: Why using bacv instead of bacnet as prefix?
Ege: It was suggested by the Manu Sporny, to avoid confusion between the schemas and the prefix
Dogan: Can we update the main document to link to this protocol binding?
<dape> w3c/
Ege: Yes for now, in future we'll have a more structured process
Cristiano: The modbus protocol binding needs to be updated to match
<kaz> Issue 120 - Binding Prefixes - closed
<kaz> Issue 119 - Modbus Prefix - comment added
Dogan: I'll prepare the PR to link to the main document and doublecheck the prefix
Modbus Type
PR 161 - Well-know Media Types content paremeters
(kind of long discussion)
Ege: protocol specific?
Cristiano: yeah
… content-type approach
Luca: confirm we should not use the content-type here
Cristiano: true
… but still need some discussion
… may be some corner cases
… the information is inside of the content-type
{
// ... other fields
"content-type": 'text/plain;charset=UTF-16LE'
"endianness"=BE // <-- what does it mean? we should not allow BE here.
}
Luca: if we want to add something customized, would get problems
… should look into where to put what
Cristiano: very low-structured data
Ege: Modbus uses binary stream, and endian to be specified
Luca: how to interpret the data?
Cristiano: three-step approach?
Kaz: think this is a bigger problem for WoT about how to deal with binary stream data
… should not directly dive into Modbus sensor data quickly
… it's kind of like regenerating the mechanism like pack function from Perl or Python
Cristiano: should have some generic framework
… because the binary data may possibly be some media stream data
Ege: would like to close this PR without merging
Cristiano: agree
(closed)
Issue 293
Issue 293 - [Modbus-binding] type conversion based on byte and word order
specifically Sebastian's comment including a list of bit order variations
Ege: this is a list of existing variations
… Siemens' SayWoT has three variations
modbus:type (string): integer/int, uint, boolean, number/float, string modbus:wordOrder (string): "HighWordFirst", HighWordFirst, LowWordFirst modbus:endian (string): "bigendian", "bigendian", "littleendian"
Ege: if we go for this direction, there is some library
… we need to make decision
Kaz: not sure if this discussion is really included in the scope of the WoT binding templates, because we're diving into the discussion about how to convert binary stream data (e.g., Modbus sensor data via Modbus protocol) to HTTP response.
Daniel: 3-term approach seems to make sense
<Zakim> dape, you wanted to the 3 term approach would require to specify what combination is not allowed
Luca: the binding protocol for modbus has to support the protocol as it is defined, modbus-rtu is a wire protocol and modbus-tcp is a defined serialization of that in TCP
Kaz: I still have difficulty with this discussion
… If Siemens' sayWoT uses only those three parameters (modbus:type, modbus: wordOrder, modbus:endian to handle Modbus data), we can't tell if that mechanism is really enough for all the possible use cases. So we should clarify possible data variations for Modbus systems in general, e.g., possible message frames using both ASCII mode and RTU mode with potential history management (e.g., 100 frames per sec or per hour)
… that's why I suggested we clarify some more Use Cases for Modbus binding
Luca: we can't fit all the possible variations. just can fit integer/float
… so this would confuse people who have not used Modbus data
… we need to clarify the mechanism step by step
… also what to be handled by what
… we're solving interoperability issues
… Modbus world is very different from ordinary HTTP world
<luca_barbato> https://
<luca_barbato> https://
TD Next
Reorganization
Ege: (shows the MD)
… there is a pullrequest
wot PR 1158 - Reorganization of TD Work Items as Separate Documents
Ege: splitting the content into several sub documents based on the bigger categories of the work items
… would make the document nicer
(merged)
Registry
wot PR 1150 - Expand analysis of "Custom Registry Mechanism Registries"
Jan: (goes through the MD)
Ege: much nicer now
… for example, good point about media source registry
… also "first come, first serve" policy
… would like to know about when the registries are created as well
… e.g., TTML registry
Kaz: to see if the registry is active?
Ege: right
… any objections to merge this PR?
(none)
(merged)
AOB
Ege: would like to talk about project management next time
[adjourned]