Meeting minutes
<Ege walking through Agenda>
Organizational
Minutes
Ege: Minutes look good -> minutes are approved
TD Call Slot
Ege: Who should be present in calls?
… McCool cannot join (always)
… editors vs. moderators
… moderators should be joining the calls
Kaz: Do we need feedback from/discussion with McCool?
Ege: McCool is editor
… anyhow, he cannot join
… prioritize moderators & staff to filter out slots
… possible times in CET
… Monday 14-17
… Tuesday 13-15
… Wednesday: 16-18
… Thursday 15-16
Ege: Will send Doodle poll
Kaz: Okay with creating doodle poll
… if we need McCool, current slot would work as well
… is he available in all slots?
Ege: No
Koster: McCool mentioned we should not decide based in his availability
Kaz: In that case the current slot now seems fine
Ege: A bit late in Japan
Koster: Compromise is to schedule 1 hour at another time
Ege: Okay, let's add current slot to Doodle
… ideally we pick 2 times 1 hour slot
Ongoing General Topics
Ege: Small things on TD 1.1 Publication
… readme fix, see w3c/
… I think we can merge it
Ege: Small PR on resources, see w3c/
… carry over changes from TD to resources
Ege: Merging
Kaz: Question on TD draft and resources
… agreed to move forward in main call
… these are the final changes, correct?
Ege: Yes, didn't touch html
Kaz: Ideally resources should not be changed anymore.. for a while
Ege: Agree
Intro from Dogan
Ege: Dogan is here
Dogan: Working at Siemens, Building infrastructure
Binding Templates
PR 298
Ege: Guide document: w3c/
PR 309
<Ege> https://
Ege: BACnet PR - URI Variables: w3c/
Ege: Opinions have been collected in issue
… discussions where to put information from application layer
… initial idea from Dogan to still keep it in URI variable
Dogan: Talked with Klaus Hartke also
… what is a good example for URI variables
… for property affordance
Ege: Example 32 from TD is service, not a thing.. correct
… use case ... filter big chunk of data
… some solutions out there use uri variables to choose time frame
Koster: at IETF, URI variable create new resource
… separate resource
… like alternate syntax
… existing resources need to be accommodated by TD that use URI variables
… maybe it should be discouraged ... it is kind of a dilemma
Ege: 2 ways to use URI variables
… really like new resources in path
… second, parameter to existing resource
Dogan: Concerns
… will BACnet accept change
… I think they are tolerant... need to go to the other groups
… second, protocol specific ?
… main question
… URI variable for me is to retrofit existing device
… need to allow for customization
… graceful degradation
… in building automation there is prioritization and BACnet allows it
<kaz> BACnet Binding Template - 7. Examples
Dogan: requirements belongs to domain
… fixed priority is not sensible
… URI variable gives this freedom
… protocol level, not affordance level
… write priority is important to us
Ege: covIncrement is not really a URI variable ...
… Luca proposed a different term
Dogan: URI scheme can change ... for TD 1.1
… could have better solution in TD2
<Zakim> Ege, you wanted to react to mjk
Ege: an alternative is to have covIncrement on affordance level
Koster: creating URI schema is an option
… in real systems there might not be conflicts
… I think it makes sense ... to create standardized extensions
… write priority is a domain requirement
… we could add that as well
… some applications might use fixed priority
… maybe this is not a good enough solution
Dogan: Discussed with Klaus
… standard parameter
… WoT is domain independent
… topic for TD 2.0
Koster: Yes, we need to find a way to accommodate that in 2.0
… somehow a missing feature
Luca: Let's clarify what URI variables is
… problem I am seeing ... additional concept
… should be part of protocol detail
… URI variables is additional fields to data schema
… for specific BACnet problem .. like write priority
… being pragmatic .. use dataSchema
<kaz> related Issue 302 - URI Variable for BACnet
Luca: Suggest to make it as simple as possible
Dogan: Thanks for the comments, I have to leave...
<kaz> [ Dogan leaves ]
Ege: Comment to Luca ...
… <showing scripting API code>
… should not change for other protocols
Luca: At the moment the devices are BACnet only ...
… let's go with an easy solution
… should work on solving this in 2.0
Koster: for different priority levels one could create a different resource
Ege: I see
Koster: my other point, for GET and OBSERVE there is no dataSchema we can send
… URI variables allows to send this kind of data
… not sure if we can use additionalSchema
Ege: I will close PR 309
… create new PR and add warning (as suggested by Luca)
Luca: +1
td.next
PR# 1919
<kaz> PR 1919 - WoT toolchain diagram added
Ege: addresses tooling issue
Mahda: explains figure describing the toolchain
Madha: actors are represented in the top left of each task box
… step ordering is represented in the top right of each task box
Kaz: the one big diagram could be split into phases with an explanation for each phase
Ege: there are relationships
Kaz: some parts like ontology processing could be separately described
Mahda: there could still be an overview from end to end
Daniel: the whole idea is to document the current behavior and dependencies, the complexity is because it is complex and we do need to simplify the workflow
Luca: if the plan is to make the process simpler, this is a good place to start as-is. it's a clear picture of the shortcomings
<JKRhb> +1
Ege: So it's better to spend the time simplifying the process rather than optimize the diagram
… schema generation is missing
… we should indicate which files are important for deliverables
Mahda: there is arrow notation on the chart to indicate inputs and outputs that go into the spec
… could generate a legend to describe these
Ege: it would help to have a legend
Kaz: If we want to improve the workflow, we should generate a manual, a concise description of what we want to change
… to clarify what the procedure is
… for generating the documents from the initial inputs
Ege: are we ready to merge this?
PR# 1157 work item document
Ege: we reduced redundancy in the document
<kaz> wot PR 1157 - Reorganize work items
Ege: any objections to merging?
… merged
Ege: we need to move the binding work to its own section below
PR #1150
<kaz> wot PR 1150 - Expand analysis of "Custom Registry Mechanism Registries"
<kaz> Rendered Readme.md
Jan: task was to summarize existing registry mechanisms
… summarize the content and the process for each registry
… then a general summary of points we need to consider
<kaz> [ Mahda leaves ]
Jan: maybe there are some more categories but this is a first step
Ege: looks like Xpointer is an outlier
Jan: it's an early example and bare bones
Ege: other questions, which are most recent and which are active?
… what about updating entries and versioning?
Ege: it might be important to have a policy of new versions for updates
Kaz: another question is what can be learned and applied to our solution
Ege: when we get the other inputs we can review them all together
… this PR looks good, will look at it for another week.
Jan: will look at adding a table of comparisons
Ege: any more comments?
… any other business?
… adjourned