Meeting minutes
minutes
<kaz> May-31
McCool: we reviewed different PRs
McCool: I recently worked on TD signatures, some updates later
… we accepted different refactoring PRs
… farshid have you completed the updates to the mentioned PRs?
Farshid: yes
McCool: I have not yet discussed about slack with Kaz
… but we have time
… any objection to publish the minutes?
… ok minutes accepted
Pending PRs
PR 192
<kaz> PR 192 - Addition of change log WD2
McCool: let's start simple, PR 192 is about change log
… farshid already reviewed and approved it
… we can fix it up later
… if we find any issues
… any objection?
Farshid: not an objection but it would be cool to have dates or timestamps for features
McCool: it should be new changes after the last WD
… anyway we'll fix it later
PR 195
McCool: another easy one, it is just a bug fix
… any comments?
… ok merged
McCool: does the sub prs provide all the changes requested by Ben?
Farshid: they contain more than that, some updates in the text for example
McCool: Ok I'll propose to merge them and than close the original now.
PR 191
Farshid: we reviewed it last time
McCool: seems ok
… merged
PR 196
<kaz> PR 196 - Refactor Directory Service API TD (split events)
McCool: no review from Ben here
Farshid: now we have three affordances
… all nouns
… we don't have type for partial TD
McCool: diff is confusing
… in the created event
Farshid: it was called full
… it was clashing with the update parameter
… diff is more consistent
McCool: is ok for now, let's go on and see if it works out
… we can improve the text a little bit by saying that some query parameters are ignored for a particular event type
… I am ok with the current shape, adding a small point
… any objection to merge it?
… merged
PR 198
<kaz> PR 198 - Notification API: pass event type in HTTP path instead of query
Farshid: this is a change in the api, not just a refactoring
… you can now subscribe to two event types at a time
McCool: it is a little bit protocol specific
Farshid: but also extensible
McCool: url should be opaque in general
… I am ok merging it
Farshid: actually you are right td does not allow Event filtering
Ege: you could use a subscription payload to achive it
McCool: to be discussed in the TD it self
… filtering by urls is better than nothing
Ege: here is custom workaround
… for the td we need something generic
Cristiano: yeah maybe something like a root form
mc creating an issue about subscribing to a subset of events
184
<kaz> PR 184 - Refactor Directory Service API TD
McCool: this is the original pr, we agreed to close it without merging cause it got replaced by the other one
Farshid: there was also an issue
… 133
<FarshidT_> https://
https://
<FarshidT_> https://
McCool: ok PR closed
… closing also the issue
… above
testing
McCool: farshid can you attend testing calls?
Farshid: yes I'll be there on Wednesday and Friday
Ege: we need a testing plan
McCool: what are the features that we need to test?
… we need a fine tuned test suite
… not just comply to our TM
Ege: we need to interact with an API
McCool: I think so
McCool: there is also peer-to-peer
Ege: how would it looks like?
McCool: there's also introduction
… if the state is observable we need to check it
… but there might be apis where the state is private
… triggering errors might work
… what do we have for testing?
Farshid: we have a full test suite for go
… it would be really cool to have it in python
Ege: we just need the output
Farshid: yeah but how to use for other implementations?
McCool: we should create an id for each testable feature
… and create an csv file
Ege: we don't need a brand new test suite
… just a tool to run
… and the output
McCool: what is required by w3c is a test result and a test plan
… it comes to us to define features
… we don't even need to check your code
Farshid: the suite is test oriented
<Ege> tdd-reg-create-known-td
Farshid: how would we report optional features?
McCool: just put everything pass or fail than we can later ignore it
Farshid: if you are getting or patching there are many things to verify
Ege: for creation for example there should be two child assertions
McCool: why don't we try to use Farshid suite and name each test with unique name?
… and understand the feature map we need
Farshid: ok
McCool: farshid does not have sparql support
… andrea does not have jsonpath there
Andrea: yes it supports jsonpath, but we don't have tests for it
<Ege> @farshid is this the running tests for linksmart: https://
McCool: ok we have few months to fill up the gaps
… do we have a existing test suite for jsonpath?
Andrea: I don't know, we have it for sparql
… the benchmarks generate the data and than test it with queries
… I have to check if this can be adapted for TDs
McCool: ok to define a plan
… but which version of the spec we will use
… I would use the current draft
… we should freeze the editor draft
… for the next two weeks and then use the report to pin point gaps etc.
Farshid: can we do editorial changes
McCool: yes
Farshid: I can provide tests for multi cast dns
McCool: we don't have to test qr code
… we just test things that we defined changes to other standards like the service type
McCool: also we need to test security
McCool: please check if there are some test suite for json-path
McCool: closing the meeting see you tomorrow in the test call
<kaz> [adjourned]