Meeting minutes
Minutes
<kaz> Feb-13
Ege: We will go through the minutes, if you have remarks let me know
Minutes approved
Ege: We invite Luca Barbato to this call
Pull Requests
PR 2080
<EgeKorkan> PR 2080 - fix: align JSON Schema with JSON-LD @context format
Ege: Pull request created by Jan
<kaz> Changes
Jan: I noticed that JSON Schema allows for integer based values in the context, which is not allowed in JSON-LD, and if we put one of these TDs in a JSON-LD processor it will reject the TD. This PR updates the JSON Schema to reject this kind of TD. While adding this I noticed another bug, added contains statements to make this fix work, now only
… objects and strings are allowed.
Ege: Now you are rrquiring both URI versions to be present
Jan: old context URL is also correctly enforced
Jan: Maybe I need to revisit the part of prefixItem
Ege: the old URI V1.0 should be the first and then the second V1.1
… update it to the resource directory or not
dape: I would suggest that if we create some valid and non-valid TDs to validate this new schema and that are sure. Maybe we can add some unit test and ensure that the changes don't add a regression
Ege: There are some test scattered, some from Cristiano, and some in the Playground, but this kind of test does not exist. The toolchain done by Mahda also includes this kind of testing
Jan: This is a very good idea, and will try to add some test cases and can add these new test cases to our list
Ege: shows in the TD playground the test examples
ege: does anyone have any comments whether we should push it to the upstream or keep it here?
None
PR 2081
PR 2081 - Make contentType optional in ExpectedResponse and AdditionalExpectedResponse classes
Ege: make contentType optional in ExpectedResponse and AdditionalExpectedResponse classes
Jan: The main fix is in the TTL file, what was a bit complex is that we need to adjust the assertion in the spec correctly
Ege: the default cannot be assumed, but one of the main thing from the spec is that "the content type defaults is removed". But the main question I had is, but what about the normal contentType, we don't say the same for the request.
… if we don't do the same we will have a different behaviour, this was also a complaint from the BACnet binding, because it makes sense, because they have to override it all the time. But, if we go for the initial connection direction, we define it once and then we don't need to change it
jan: now I understand your comment on Github, so I think moving the default there would make sense
Ege comments on the PR
dape: While I understand the problem that most of the time different bindings have different defaults, now in the initial connection we need to define these defaults. I wonder about backwards compatibility and that making people aware that these defaults need to be set. Now this is shifting a bit, I don't know what the consequences would be
Ege: the explanded TD 2.0 would not have any compatibility issues, TD1.1 consumers should look at the form.
… oh no, what you are saying is still an issue
Ege: I think this would be a breaking change
Luca: I guess one part is that we should consider the fact that the consumer and the Thing or servient can be completely free outside the content type on their own, so it is not too terrible. The content type is there to give the consumer the chance if a form is to be completely avoided before trying, but depending on the protocol the content type
… is to be decided.
ege: by decided do you mean automatically, via content negotiation
luca: yes, if the servient is using a protocol that allows you to define a content type, omitting it is not causing any problem
Ege: I guess we can do some examples
luca: this is something that depending on the protocol can be not a problem
Ege: I'm not sure if we can confidently say this
Jan: This depends on the use case we have
Luca: my point is that the content type could be optional, could have a default, could be redundant depending on the protocol we are using. Ideally we say at the TD level is optional, but on the binding level is mandatory, because the underlying protocol doesn't have a mechanism to know the protocol type
Ege: I would say that in Modbus or BACnet there would not be a way to specify, the concept does not exist.
… in some cases maybe it makes sense to not specify it
kaz: I was wondering about the potential impact on the scripting API spec, this might have some impact. We need to think about the overall mechanism.
Ege: It is a valid point, we should be aware of the impact on other parts of the spec, I think there will be some changes to the algorithm of consumed Things at least on the binding level
Ege: Daniel would be good if you could take it back to the Scripting API and check the impacts
Dape: Yeah, once you push this PR I will discuss it
Jan: I think there was also a discussion with Klaus, whether he suggested that this vocabulary term could be removed and only have it at the protocol binding level. I think his point was that having the content type on the Form level might not be feasible or compatible across the protocols. Maybe we need to have further discussion to see how we
address this
Ege: good point, I need to dig up the link to the discussion
Ege: any other comments on this PR?
Initial Connection
<kaz> PR 2058 - Initial Connection Feature Description
Ege: Last week I showed this PR, the first discussion item was adding some information on the Readme, that was what I did.
… the other things we discussed was about expanding the TD that should go through strict validation, any level of compaction is difficult to validate with JSON Schema
… if somebody would like to get into these stuff, if someone wants to understand how the JSONLD expansion and compaction works would be valuable
Luca: what do we want to do regarding the JSON-LD transformation
… why do we want to do that?
Ege: the main thing I showed last week was an example of a TD with the initial connection feature description, then the problem started to happen when I went to invalid TDs, it was not easy to invalidate that TD.
Luca: This TD that you show is not invalud
Ege: but we need to know the base, and this is currently not inside this TD
Luca: if you are able to fetch the TD, you have a default to fetch the defauly connection
Ege: we don't have such an assumption
Luca: In V1.1. we have that
Ege: I am sure we do not that have that assumption
Luca: If you are ommiting the base in V1.1. you have to figure out the base. In the implementation in Rust, I had to figure out how to get the TD, I am fairly sure that in the past year at least I managed to have at least to deal with that. Either I managed to mis-read it, but that was the situation.
Ege: I mean this can be something, but to my knowledge this is not the case by the specification
… anyways, this can be the security for instance
luca: if we always have a default it would be better
… when we have something that is an impossible combination, the current default is using a schema that is not supported by the protocol or the URI schema, these two situations are the way we can find out something is invalid by parsing it. having the parser to figure out what is invalid after everything is parsed.
Ege: the discussion with defaults we haven't talked about yet, there was discussion on the compacted TD not being able to validate, the validation is complex because the error can happen in different places.
… thats why we said maybe we should look into the JSON-LD compaction and expansion algorithms
Luca: these are very different, I have looked on to the JSON-LD spec, but long time ago, but it felt different on how it works, but maybe I'm wrong
Ege: we don't want to exactly use it
… what is expanded TD, mandatory form elements, everything is contained in the form to be reused, next week we should discuss the href, whether it should be absolute URI or not?
Luca: I would say that the final expansion should have absolute URIs
Ege: Lets discuss this next week to reach a decision
Luca: if we want to start thinking, we should make sure to go in the one direction or the other, so that we can compact a TD and ideally be able to return to the starting point.
Ege: next week Wednesday is cancelled and only on Thursday there will be the meeting
<kaz> [adjourned]