Meeting minutes
previous minutes
<dape> Previous minutes, see https://
Daniel: we merge a PR from kaz and then discussed about the new term in architecture: PartialTD
… it was a long discussion
… and it is still open
… we'll discuss today again. Cristiano made a PR about it
… we discussed also about versioning. The issue is still open. We need more experience about the problem
… any problem with the minutes?
Crstiano: ok
Zoltan: ok
Daniel: ok, minutes published
open PRs
<dape> https://github.com/w3c/wot-scripting-api/pull/291
Daniel: minor issue
… propertyReadHandler should return InteractionInput
… previously it returned any
… in the same PR I changed also any types in TS definition
Zoltan: in web IDL we could use undefined and in TS use void
Crstiano: I agree with Zoltan
Daniel: I agree with you too, I'll change the PR accordingly.
… ok issue resolved.
… next PR is from Cristiano. It is about PartialTD
<dape> https://github.com/w3c/wot-scripting-api/pull/289
Daniel: the changes are lager than I expected
Crstiano: I changed the produce method and the ExposedThing constructor
Daniel: zoltan commented that the PartialTD type could be renamed to init
… from my side I'd a minor change. Basically, rename the argument and mention the details in the algorithm
Zoltan: we can separate the type name from the validation algorithm.
… I prefer a more web platform compliant term like ThingDescriptionInit
… decuppling this two would improve the understanding
Daniel: TD is used both as argument in construction for consumed and return type with the getThingDescription method
… I'd like to reuse the returned object from getThingDescription as a produce argument
Zoltan: it is part of the use case. We still could use thing Init with a better description
Daniel: as I user I'd like to use the full TD returned by getThingDescription without any processing
… quite similar to the algorithm defined in the PR
Zoltan: my comment it's only about the name. I agree with the rest
Daniel: ok. For sure we need the algorithm as presented in the PR
Zoltan: my opinion is that the input is an object. We could use that type but the best practice is to name it differently to convey semantics.
Zoltan: we should define also an algorithm to validate the output of the produce method
… my point is that I don't like the name of the type. PartialTD is a bit confusing
<zkis> CA: introducing a new term might be confusing
<zkis> ... partial TD term is used in our use cases
<zkis> DP: partial TD is only used in Scripting
Zoltan: his proposing to remove the PartialTD from the architecture
Zoltan: yeah it could be the right choice
… we need a good name and we can move on.
Crstiano: My last open point is weather if a partial TD will not ever used somewhere else
Daniel: maybe it is closer to the ThingModel
Zoltan: we could define a ThingDescription and add a new object called "input"
… there we could even also accept a ThingModel
Crstiano: let's start with ThingInit
Zoltan: it is better ExposeThingInit
Crstiano: right
Daniel: so we need just to rename PartialTD to ExposeThingInit and then discuss the algorithms
Crstiano: the algorithms need some more work
Zoltan: the algorithms are fine IMO
Crstiano: there are some TODOs
Daniel: yes we could discuss that next time
Crstiano: we could use JSON schema patch feature
Daniel: yes it was proposed by Andrew
… it would be much easier to have a external algorithm
Kaz: adding this kind of algorithms is good. I think we should clarify the reasons why we are adding this capabilities, as I mentioned in other calls
Daniel: the intent now is to remove partial TD from architecture, because we are the only one to use it
Kaz: we're talking about partial TD, TD fragment and Thing Model during the Architecture call and the TD call. So in any case, we need to continue the discussion on this in the next architecture call.
… we are on the same page.
Zoltan: we need this concept also in other places. So it may be probably better to define it in the architecture
Zoltan: for example in the node-red runtime they are probably using a similar concept
Daniel: sure but it is up to them how to initialize an exposed thing
Zoltan: but they should follow a common algorithm
<zkis> CA: maybe not every client would accept the same algorithm for Thing init
Crstiano: probably other implementations would not follow a common algorithm
Zoltan: it is not like they can do whatever they want
Daniel: how internally set up the whole exposed thing is not strictly specify. It is critical to provide the some outcome
Crstiano: I agree
Zoltan: so Why are we defining the algorithm in our spec?
Daniel: it is difference it is for scripting consistency.
Daniel: there're a bunch of details that would need to be specified in the exposing process
Kaz: scripting api task force can define its terms. We should clarify why we end up with this decision. Examples could help a lot. Also how to use this partial TDs in applications
<zkis> Summarizing, the TD spec specifies the expected outcome (TD), not how it is achieved when creating ExposedThing
<zkis> In Scripting spec, we need to specify the interop expectations in the algorithms, for instance how to handle input for ExposedThing init
Zoltan: we need to ask to the Architecture TF if they are interested on the PartialTD definition
… later we can move the discussion to the architecture
https://
Crstiano: please add a comment about today dissussion in the PR above.
Daniel: I'll try to report our point in there.
Crstiano: I'll finish the PR, please check the alogorithms
Daniel: Ok, there are some issues left
… but we are overtime
Zoltan: I could stay more
… about implementation feedback you could raise an issue
Daniel: I just felt that the new changes add a lot of complexity
Zoltan: streams are widely used for handling generic data format
… web platform is using it
Kaz: out of time :)
<kaz> [adjourned]