Meeting minutes
previous minutes
<kaz> Jan-25
No objections, approved.
PR 289
<dape> PR 289 - Add definitions for partialTD
<dape> related with wot-architecture issue 574
Daniel: related to the issue discussed in Architecture
Daniel: the PR was merged, so we have a definition for the Partial TD
… since it may be useful for other use cases as well
… so now we have the PR from Cristiano
… we decided last time to rename PartialTD to ExposedThingInit
Cristiano: yes, it's been a minor update, just a name change
Zoltan: usually we don't make separate sections for dictionaries
Cristiano: but we have 2 algorithms
Zoltan: ok then it makes sense
CA presents the PR
Discussing structuring of the ExposedThingInit section into the produce() section
… as subsections of produce()
Cristiano: another thing, what to do with the table for generating the partial TD
… and how to deal with possible differences in implementations
… in order to be interoperable
… also, take care of mandatory definitions (like security, context, ...)
Daniel: if someone specifies a scheme that is not supported, it should replace or handle it
Zoltan: usually we need to specify in the algorithms how to handle these
Daniel: for instance, could href point to another Thing?
Zoltan: do we do syntactic or semantic check?
Cristiano: syntactic
… the app might not want the impl to replace the href
Zoltan: the TD should give us possibility for that
Cristiano: we could use relative URI here
Daniel: the problem is that e.g. node-wot uses the input to generate a full href, and the app cannot have that knowledge
Cristiano: the input from app should be respected up to the level of definition: name, partial URI, or full URI
… if it cannot be respected, then an error would be reported
… but the parts not specified should be completed by the runtime
… also, understand that we cannot use other URIs than the ones we own
Daniel: need to check this
Daniel: impls should not allow other origins in the input
… but rather use the handlers for accessing external URLs
Cristiano: also have a use case that the address generated by node-wot is not what was expected by the app
… anyway, I agree, make it simple and don't accept other origins here
Zoltan: also need a default handling for security input (e.g. no-security)
Daniel: difficult to provide the right credentials for the exposed Thing
Cristiano: will try to propose something and discuss in github
Zoltan: it would be nice if the TD TF would define the exact TD producing
Daniel: the TD TF is concerned only about the decoding, not the encoding
… the only thing to make sure is that everyone decodes the same way
Zoltan: so you say it's application's domain to describe the encoding
Daniel: well, yes
Zoltan: we should separate the pure syntactic checks from the semantic checks and transformations by impl
… and feel it's a gap if we don't specify the transformations
Cristiano: agree with that
Daniel: so let's start with syntactic and then decide
implementation feedback
<dape> Issue 292 - Simplification of interface InteractionOutput
Daniel: InteractionOutput is too complex
Zoltan: we need to support other content types than DataSchema
… the TD permits that and it was a gap
Cristiano: I also wonder why can't we have streams
Zoltan: we could raise up in the main call if we want to stick to DataSchema
Daniel: just not sure about this in real life
… this will be a problem in many implementations
Cristiano: but streams is optional, the value() function can throw
Zoltan: I think any impl based on http or coap library can do it out of the box
Daniel: ok, let's discuss further
adjourned