Meeting minutes
Agenda
Lagally: terminology discussion, etc.
McCool: would like to briefly report back from the APA call
APA report
McCool: kind of related to the discussion on the "human readable information"
… also discovery on progressive disclosure
… related to limited bandwidth of UDP
McCool: accessibility for the end users and the developers
… could select your purposes
Lagally: sounds like we need discussions on requirements
McCool: would put them together
… related to discovery, etc.
<benfrancis> (Apologies I can't make the architecture call today due to a conflict)
McCool: so how to write up them?
… maybe need documentation for horizontal use cases
+1
McCool: could you please create an issue?
… or I can do it right now
Lagally: good
Prev minutes
Lagally: (goes through the minutes)
… FPWD feedback for wot-profile
… made a resolution on the common data model
Lagally: any problems with the minutes?
(none)
approved
WoT Architecture terminology - Partial TD
<McCool> (move earlier) documentation issue created: https://
Lagally: first of all, changes from the FPWD
… merged
… then "Partial TD" definition
PR 577 - Partial TD definition
McCool: partial TD can omit some of the TD mandatory elements
Kaz: we should clarify which part could be omitted
… based on our purposes and should show examples
McCool: right
Cristiano: there is some example from the scripting api draft at the bottom
Koster: partial TD doesn't validate a Thing
… should provide some validation mechanism for them
Kaz: yeah
Lagally: that would be a request for the Scripting API
… would propose we merge this PR 577 itself, and then add further improvement later
Cristiano: do we have any other use cases for "partial TD" ?
Lagally: we'd like to know what is the actual use case of the Scripting API as well :)
Kaz: +1
McCool: some TD based on the fragment as well
… btw, what about the "TD fragment"?
Lagally: let's close this PR for "partial TD" first :)
McCool: ok
Lagally: (merged it)
… (then visit the merged definition within the wot-architecture/index.html)
… (and add some tweaks)
… "it is not required to contain all the mandatory elements"
… "an example usage of a partial td is in..."
Architecture - TD fragment
Lagally: do we have any definition for "TD fragment"?
McCool: could do a PR right now for discussion...
… would mention discovery use cases
McCool: fragment doesn't have concrete structure
Lagally: do we have any concrete definition?
McCool: valid JSON corresponds to internal elements of the TD model
Koster: we can talk about SHAPES as well
<mlagally> https://
McCool: there is some definition within the comments in Issue 453
[[
TD Fragment =
substructure of the data model of a TD.
It is a valid object structure that can be validated syntactically against the TD datamodel defined in chapter 5 of the TD spec, however im may omit some context that allows full validation.
Note: In JSON represention it must be a valid JSON however could be just an inner structure omitting outer elements, curly braces etc. As a use case the TD fragment is useful for Discovery results returned by a JSON-Path query.
Todo: McCool to provide a link to the Discovery spec
]]
(some more discussions)
McCool: adding a link to the discovery spec is easy
Lagally: let's start with this
… (add tweaks to wot-architecture/index.html for that purpose)
Cristiano: thinking about if it's TD fragment is a kind of TD
<McCool> we should use this to refer to WoT Discovery. But also, a direct URL is not a good idea, it should be a reference (and Scripting ref in Partial TD should also be a reference)
<McCool> https://
Cristiano: if we're talking about discovery that should be a TD
(some more discussions)
McCool: one requirement is validation method by JSON Schema, etc.
Lagally: (adds some more tweaks to the definition of "TD Fragments")
McCool: gave a comment on reference above (@@move McCool's comment here)
… and chapter title of the specs to be mentioned there
Lagally: ok
… (reads the initial definition within wot-architecture/index.html)
Google search results for "JSON fragment"
[[
A JSON fragment is a JSON that does not have an Object or an Array as the root. If you do need the ability to encode JSON Fragments, you can change the jsonString function to handle the fragment cases in a different way: The function now encodes JSON fragments as simple strings.
]]
Kaz: maybe we can borrow part of the definition of "JSON Fragment" as well, can't we?
McCool: interesting
Lagally: let's close this edit here on wot-architecture/index.html
Kaz: ok
Lagally: (creating a pullrequest based on the discussion so far)
… adding "TD Fragment" definition as proposed in arch call 2 weeks ago...
… kaz, you might want to create an issue for the "JSON Fragment" definition part
Kaz: ok
WoT Profile - Max nesting of elements
Lagally: (visits the preview)
Lagally: ok to merge it?
(no objections)
merged
WoT Profile - Max size of a Profile-compliant
Lagally: 65000 bytes as the limit?
Cristiano: was also thinking about 60000 bytes or so
McCool: 32000 could be also enough
Kaz: would be better to provide a mechanism to change the limit
… I'm OK with putting 32k or 64k as the default limit value, though
… some small devices could have less than 32k-byte memory
Lagally: it would require more than 32k-byte memory to process TD
Kaz: I'm not sure if 32k-byte memory is the unique threshold...
Lagally: (adds a note: smaller devices don't ned to buffer the entire TD but just can pares it sequentially with a much smaller buffer.)
Cristiano: a Thing Directory might accept only a limited size of TD
McCool: always should be user-configurable
… one option is accepting only a core profile
Koster: we don't really have a future view
… one possibility is having a link
… a simple TD might be smaller than 32k
Kaz: maybe I should have been clearer
… for the "core profile" or anything for smaller devices, having 32k or 64k as the limit is fine
… but the TD itself should have a capability to define the limit and the limit value for the "core profile" could be 32 or 64
Lagally: would suggest we continue the discussion on this issue 66 on GitHub
… and revisit it next week
WoT Profile - Max number of objects
Koster: do you have any concrete number in you mind?
Lagally: maybe around 200-300
Lagally: what did we see during the PlugFests?
Ege: we expose the devices
… rarely see more than 10 properties and actions
… but the total number is not problematic
Lagally: are you talking about the range?
… e.g., 10-30?
Cristiano: was also thinking about that
… the range of 10-30 is fine
Kaz: if the restricted device can process the objects one by one, maybe multiple objects can be also processed
<Ege> an example can be this popular RPi HAT: https://
Kaz: so we should consider "maximum number to be processed at once" as well
Lagally: ok
Kaz: of course I can agree to have a "recommended number", though :)
Koster: discussion by zigbee as well
… typical zigbee cluster has 20-30 affordances
… may have a bunch of messages (e.g., hundred of)
… modbus devices have 128 registries
… 200-300 would make sense
Lagally: maybe 256?
… or 250?
Koster: a little bit cautious...
Lagally: where is this limit to be considered?
… we're talking about some microchip
… why don't we pick some reference device
… e.g., Arm Cortex MO with 16k RAM
Kaz: +1
… we should clarify what device to be considered here
… e.g., TV set or vending machine
Lagally: yeah
… we don't have to put everything on the memory, though
Lagally: can get rough estimate of the data size as well
… 8 bytes for name, 8bytes for value
… 2048/(8+8) = 128 elements, possibly
WoT Profile - Events are loosely constrained
Lagally: let's talk about this issue next week
Ege: ok
Lagally: need to close the call now today...
… if anybody has any concrete idea on PlugFest TDs, please let me know
[adjourned]