- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 08 Mar 2021 12:30:45 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/01/28-wot-arch-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT Architecture
28 January 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Jan._28th.2C_2021
[3] https://www.w3.org/2021/01/28-wot-arch-irc
Attendees
Present
Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan,
Kaz_Ashimura, Michael_Koster, Michael_Lagally,
Michael_McCool, Tomoaki_Mizushima
Regrets
Ben_Francis
Chair
Lagally
Scribe
kaz
Contents
1. [4]Agenda
2. [5]APA report
3. [6]Prev minutes
4. [7]WoT Architecture terminology - Partial TD
5. [8]Architecture - TD fragment
6. [9]WoT Profile - Max nesting of elements
7. [10]WoT Profile - Max size of a Profile-compliant
8. [11]WoT Profile - Max number of objects
9. [12]WoT Profile - Events are loosely constrained
Meeting minutes
Agenda
[13]proposed agenda
[13] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Jan._28th.2C_2021
Lagally: terminology discussion, etc.
McCool: would like to briefly report back from the APA call
APA report
[14]APA joint minutes
[14] https://www.w3.org/2021/01/27-rqtf-minutes.html
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
[15]Jan-21
[15] https://www.w3.org/2021/01/21-wot-arch-minutes.html
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
[16]PR 576
[16] https://github.com/w3c/wot-architecture/pull/576
<McCool> (move earlier) documentation issue created:
[17]https://github.com/w3c/wot-usecases/issues/93
[17] https://github.com/w3c/wot-usecases/issues/93
Lagally: first of all, changes from the FPWD
… merged
… then "Partial TD" definition
[18]PR 577 - Partial TD definition
[18] https://github.com/w3c/wot-architecture/pull/577
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> [19]https://github.com/w3c/wot-architecture/issues/
453
[19] https://github.com/w3c/wot-architecture/issues/453
McCool: there is some definition within the comments in Issue
453
[20]the comment within Issue 453
[20] https://github.com/w3c/wot-architecture/issues/453#issuecomment-760290680
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> [21]https://www.w3.org/TR/wot-discovery/
[21] https://www.w3.org/TR/wot-discovery/
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)
[22]Google search results for "JSON fragment"
[22] https://www.google.com/search?q=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
[23]resulted PR 579
[23] https://github.com/w3c/wot-architecture/pull/579
WoT Profile - Max nesting of elements
[24]wot-profile PR 65
[24] https://github.com/w3c/wot-profile/pull/65
Lagally: (visits the preview)
[25]preview
[25] https://pr-preview.s3.amazonaws.com/w3c/wot-profile/pull/65.html
Lagally: ok to merge it?
(no objections)
merged
WoT Profile - Max size of a Profile-compliant
[26]wot-profile Issue 66
[26] https://github.com/w3c/wot-profile/issues/66
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
[27]wot-profile Issue 67
[27] https://github.com/w3c/wot-profile/issues/67
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: [28]https://
pythonhosted.org/sense-hat/api/#sense-hat-api-reference
[28] https://pythonhosted.org/sense-hat/api/#sense-hat-api-reference
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
[29]updated comments to Issue 67
[29] https://github.com/w3c/wot-profile/issues/67#issuecomment-769204617
WoT Profile - Events are loosely constrained
[30]wot-profile Issue 42
[30] https://github.com/w3c/wot-profile/issues/42
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]
Minutes manually created (not a transcript), formatted by
[31]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[31] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 8 March 2021 03:30:50 UTC