Meeting minutes
Agenda
Lagally: review of 06/22 minutes
Lagally: note that I cleaned up and merged some things we decided on last week
Minutes
<kaz> June-22
Lagally: reviewed a lot of issues at a high level, will drill down on some of these a bit more today
McCool: also, for the agenda, suggest we don't spend too much time on length limits, other things are higher priority
Lagally: agree
Lagally: publish if no objections?
… hearing none, will publish
PR 235
<mlagally> https://
<kaz> original PR 198 (closed due to merge conflicts) - WIP: event payload format
Lagally: event payload format, has a lot of merge conflict, have created new PR 235 PR 235 - CloudEvents as message payload format for WebHooks
… note there is however a lot of useful discussion under the old PR
… will close, but will link back to it from the new PR
Lagally: issue with multiple devices talking to the same cloud endpoint, single listener, multiple "speakers"
… message has to convey device; also timestamp, affordance (event source), data payload, etc.
… naive approach would be to define a JSON schema for the message format
… but if you look at what cloud companies do, there is already a format for this purpose
McCool: is this the *only* format being used?
Lagally: not aware of any other public standard used broadly
McCool: note this constrains not onl the Things but the cloud endpoints
Lagally: correct, this is for webhooks also
McCool: a little worried about the formality of the cloud events spec, also versioning
Lagally: is versioned
McCool: ok, but I think we should also have enough information in our spec to be clear even if the cloud events spec goes away
McCool: ok with merging if others are
McCool: what is the minimum implementation?
Lagally: less than ten attributes in a message
McCool: actually, count only 5 attributes that are mandatory
Lagally: if no other questions, will merge
Issue 233
<kaz> Issue 233 - Define a constrained set of link relation types
Lagally: constrained set of link relation types
McCool: also think we may want to limit the media types
Lagally: and also make the type mandatory
McCool: also, tm:* relations are allowed? Are TMs covered by profiles?
McCool: also, TMs are definitely going into the TD spec now
Lagally: not clear about manifest
… which refers to a UI
McCool: ben may have some input on, WebThings tends to return HTML for affordances unless requested otherwise
McCool: if we DO support manifest, I think we should be specific about the type is points to
Lagally: but we can leave it out for now
McCool: agree
<kaz> TD draft - 5.3.4.1 Link
Lagally: also "alternate" has a number of examples of different representations
McCool: my preference would be to insist on JSON-LD serializations of TDs in profiles
Lagally: so "alternate" does not make sense
… let me make a note about that
Lagally: anyway, these six are the suggested types
… I will do a PR if there are no other volunteers
issue 232
<kaz> Issue 232 - Define minimum set of supported languages
Lagally: minimum set of supported languages
Lagally: could look at locales supported by Java
McCool: might also want to look at browser support, take the intersection
… suggest we ask i18n team, and can also label, tag @aphillips, etc.
cleanup
PR 227
<kaz> PR 227 - Update Implementation Report
Lagally: merged impl report, that is done
PR 207
<kaz> PR 207 - updating JSON Schema Validation reference
Lagally: PR 207 updates the JSON Schema ref
McCool: just make sure this is not changing from the version used in the TD spec
… I'm not even sure we need this in profiles if TD specifies it
<kaz> [adjourned]