<kaz> scribenick: kaz
kaz, daniel and sebastian
McCool: call logistics above
... several guests for today
... IRC channels is #wot
... resources on GitHub
... schedule
... PlugFest done last week, Sep 28-Oct 2
... today Architecture/Profiles
... Oct 7: Use cases, requirements and liaisons
... Oct 13: joint meetings with DID and PUB
... Oct 14: joint meeting with APA
... Oct 15: joint meeting: with WN
... Oct 20: Discovery
... Oct 21: TD and Thing Model
... Oct 22: Scripting, Security, etc.
Lagally: holding 2-hour call every
week
... version to be published as a FPWD now
... clean up a bit, e.g., for ReSpec
... topics: FPWD review - go over the draft
... then requirements
... trying to identify requirements for standardization
... terminology as well
... then two presentations
... Sebastian on Thing Model requirements, Koster on OneDM
compatibility
... anything else for today?
Lagally: discussion with the Pub BG
Chair for the joint meeting
... FPWD publications, OneDM/Thing Model, ...
... any objections for publishing the minutes?
(none)
Lagally: approved
Lagally: no ReSpec errors now
... would like to identify owners of unassigned sections after
the FPWD publication
... this is the FPWD version, and the Architecture TF is OK
with publishing the draft
... (goes through the sections of the draft)
... Introduction, Conformance, Terminology, Application
Domains, System Topologies
... not perfect yet
... short section on System Integration
... then Requirements
... we'll detailed discussion later
... then Abstract WoT System Architecture
... WoT Building Blocks which talks about the related WoT
specs
... Thing Model, Core Profile and Discovery have been
added
... then Abstract Servient Architecture
... would like to go through the newly added sections
... and see go or no-go for the FPWD publication
Kaz: (as I mentioned the other day) we need to add the diffs from the v1 version within Appendix A "Recent Changes"
Sebastian: right. it would be
helpful.
... Taki is working for TD spec too
Lagally: ok
... created an issue on that
Lagally: had a conversation with
Matthias
... he's not active anymore and to be moved to the
Acknowledgement section
... some more as well
... also would like to get some more new
... created another issue on that
Lagally: Terminology
... definition for "Thing Model", etc.
Sebastian: I have a definition within the TD draft
McCool: would be more convenient to have the definition within the Architecture spec so that we can refer to the document for terminology
Lagally: Sebastian, please make a Pullrequest to transition the definition from TD to Architecture
Sebastian: ok
Issue 547 on terminology for Thing odel
Lagally: goes through the use cases
(Application Domains/ System Topologies)
... Editor's note for "5.5 Edge Devices"
... "TODO: (McCool) Check if the current text still fits with
recent edge computing activities."
McCool: nothing incorrect here
... should say "expand" instead of "check"
Lagally: ok
McCool: expand to capture the recent activities
Lagally: ok
... probably need a proof read as well
... new issue on "align languages use case vs application
domains"
Lagally: then "7. Requirements"
... Editor's note saying "TODO: New requirements from new use
cases need to be added here."
McCool: links to the requirements on the GitHub would suffice
Lagally: ok
... creates a new issue for that
Lagally: section 7.2 also has the same
note
... then "8.1 System Components"
... "TODO: Create introductory text that introduces the
concepts from the succeeding chapters."
... also "8.1.2 Thing Models"
... "TODO: Create section."
Sebastian: there is a PR
Lagally: 8.1.4 Intermediaries
... "TODO: add reference."
... then "8.4 Lifecycle"
... need references
McCool: any resources the other W3C groups?
Kaz: what about IETF ACE, etc.?
McCool: that is rather related to device lifecycle and would like to see application lifecycle
Kaz: in that case, we might want to see the multimodal lifecycle note
<jeff> [/jeff needs to drop off.]
McCool: might make sense though that's kind of old
Issue 552 on lifecycle intro text
s/application lifecyle/information lifecycle/
McCool: note that we have PRs not yet
merged on LD proof, etc.
... and related discussion on how directory is managed for
discovery
... think LD proof should has enough features
Lagally: what about "information lifecycle"?
McCool: need to have discussion on
information in a device and metadata like TD
... put together the obvious things and then non-obvious
things
Lagally: what is the difference?
McCool: examples of obvious things
are cameras to take photos
... to be moved to the other devices
... sometimes you might want to include personal data
... so it's not "TODO or Not-TODO" question
Lagally: the requirements depend on the scenarios
McCool: two large categories
here
... 1. data management
... 2. metadata management
... probably separate lifecyle for both
... data management should be discussed with the Privacy
group
Lagally: let me capture the points within an issue
Kaz: Michael McCool should be able to work on that but people are encouraged to provide use case scenarios for this
McCool: yeah
Lagally: can assign this issue to you, McCool?
McCool: yeah
... please put labels for discovery, past FPWD and security
Lagally: done
... creates two more issues for lifecycle
<scribe> scribenick: dape
Lagally: old editors note right before 8.7
<inserted> 8.7 Protocol Bindings
Lagally: Question to Sebastian: additional oepration types coming?
Sebastian: None planned
... default operation for unsubsribe event planned
... current text is fine as is
Lagally: Building block sections
... 9.2. Thing Model is new
... 9.3. Core Profile is new
... 9.4. Discovery is new
Sebastian: working on intro text for 9.2. Thing Model
Lagally: Introduction text for 9.3. and 9.4. is planned for past FPWD
McCool: Can expand editors text for 9.4. but actual update is planned for later
Lagally+McCool: cross-referencing between Architecture and the other docs like Discovery and TD to be handled by Kaz
Lagally: Sections 10+ do not contain
1.1. changes
... need changes sections for 1.1
... 9 issues left for FPWD (Architecture)
<inserted> Issue 558
Daniel: FYI: JSONLD has a former editors list in the top of the spec
Lagally: Talked with M. Kovatsch but he perefered to move it to appendix
Zoltan: Seems to be common to have editors kept together
Lagally: no strong opinion
... suggest keep it as it is
Kaz: we can also check commit history. please note the Editors list was imported from the WoT Architecture 1.0 version, so we need to clarify who would be the active contributors.
McCool: Suggest leaving it as
is
... suggest moving it out to improve citation
Kaz: Will check with Panasonic, but publishing the FPWD with the current Editors list is fine.
Lagally: Issue#546, marked as "past
FPWD"
... Would like to ask Sebastian to take over
... 8 minutes break before ThingModel topic starts
<kaz> [8min break]
Sebastian: Would like to start with
requirement document for thing model
... see
https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-models.md
... many use cases for thing models
... - digital twin use case
... - mass production use case
... - simulation use case
... essentially use cases where we don't need actual TD
instances
... Requirements:
... - defining common elements
... - minimum requirements
<Mizushima> --> https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-models.md thing model
Sebastian: - possible to define partial (or template based) security definitions
<inserted> 10. Thing Model from the TD draft
Sebastian: At the moment section "10.
Thing Model" is in TD
... content comes from Annex C
... previous name was "Thing Description Template"
... still discussing content type requirement
... We are trying for formalize the chapter right now
... also work on text about differences between "TD" and "Thing
Model"
... object oriented programming paradigm: class vs
instance
... Thing Model defines model for a thing: common metadata,
no/partial security, no protocol or template
Lagally: Figures contains term "template". Is thera definition?
Sebastian: Not yet
McCool: coming from URI template
Lagally: Need to explain how missing data is completed
McCool: 2 options
... 1. omit
... 2. named values
... problems like name collisions may arise
Sebastian: Chapter 10 is still under
construction
... The TD follows the ThingModel and includes missing
data/portions
... instance specific data
McCool: for security it is good to
know the type of security
... but the authorization server does not need to be known in
advance
Sebastian: Links make more sense in instances
McCool: depends on link relation
types
... some kind of links may be in Thing Model
Lagally: Good point
... brings multiple inheritance back
... how can a TD be implementing 2 Thing Models
... eg. switch and a lamp
Sebastian: extension feature will be
addressed
... technical solution is not decided yet
... re-use what we have?
... JSON schema, JSON-LD, ...
... need technical evaluation
McCool: Closeley related to
modularity
... maybe avoiding certain conflicts
... aligning with oneDM structure
Ege: w.r.t. multiple inheritance: prefer using "one" ThingModel but add support merging 2 thing models into one
Lagally: Makes sense
Sebastian: Agree also
... should clarify the approach
Cristiano: there is not only inheritance
but also composition
... need to clarify when to use what
Lagally: Agree, we will see both types
<McCool> McCool: agree with idea of doing composition of thing models (ideally still with modules) and then single inheritance ("implements" relation from TD to TM)
Lagally: how do we put things together
Sebastian: Please have a look at new
section 10 in TD document
... there are new assertions
... introduces also @type "ThingModel"
... there is also a new "placeholder identifier"
Lagally: Issue how to escape double brackets
Sebastian: We have an issue with that regard
<McCool> McCool: think we should follow existing systems in that regard (example is "mustache")
Sebastian: Note: TD document contains Thing Model definition already
<inserted> PR 540
Sebastian: I prepared PR#540 for
architecture
... added 2 paras explaining Thing Model
Lagally: Any comments/questions?
... propose merging
... no objections --> approved
... need to resolve conflict first
... PR#539
... comes from Zoltan
Zoltan: Made more changes
... scope is device lifecycle
... please let me know if there is something more or
missing
Lagally: Suggest to take what we have
and improve later (if necessary)
... suggest resolving merge conflicts and merging
... Need "owners" for FPWD issues
Sebastian: BTW, resloved merge conflict
Lagally: Okay, then let's merge PR 540
<inserted> PR 540
Lagally: back to "owners" for
issues
... I will take some
McCool: can take issue#549
<kaz> Issue 549
Zoltan: Note: huge merge conflicts but can solve them
Lagally: Time check? Agenda
check
... carry over to architecture call on Wednesday
<kaz> Updated agenda for today
Lagally: 5 minutes break
<kaz> [5min break]
<kaz> scribenick: sebastian
Lagally: Specification is in early
stage
... it has many editors note
... many details are missing
<Mizushima> --> https://w3c.github.io/wot-profile/ wot-profile draft
Lagally: however, good base for
discussion
... we need active contributions, implementations, etc.
... which features should be adopted, which are common ground,
etc.
... we need some feedback, how the current assumptions work
McCool: there are different use cases such as out of the box interoperability. are there more missing?
Lagally: first concentrate on OTB interop.
<Ege> https://github.com/w3c/wot-profile/issues/37
McCool: we need also discussion about
extensions like geo location in the TD
... however, we should limit the extensions
Ege: I provided a review as an
issue
... there are two concerns
<kaz> 5.1.22 Recommended practice
Ege: one is about events
... web sockets are very open
... other comments about small feadbacks
Lagally: many details, we should go over in detail
issue https://github.com/w3c/wot-profile/issues/37
Ege: What makes the enum special?
Lagally: is type safety and based on simple types
Chris: A concrete example could help with the enums
Ege: "format" is not supported anymore in JSON Schema
Seb: use a different term?
Ege: No, its a different
mechanism
... Type is a must, but what is about photos?
... there needs better explaination when JSON is used as
content type
Lagally: However, we just describe
Thing Model Data Types there
... Should there be an assertion saying terms not in TD are not
allowed for DataSchema, i.e. anyOf
Ege will provide a specific issue
Ege: misstake about the input of actions. It allows objects
Lagally: We running out of time. Cont. in the next call
Ege: Regarding security, shall all scopes be supported?
McCool: We should follow the security guidelines.
Lagally creates an issue about the different OAuth2 options
Lagally: continue on Wed. about the inputs from Ege
Ege: Current draft of WoT Profile is not ready for FPWD, especially the Event part
Lagally: Will be more feedback expected?
Daniel: I will read the current status
Cristiano: I will also review
McCool wraps up
Kaz: How should be the title name
of the Arch 1.1?
... something like "wot-architecture11"?
Sebastian: dot or without?
McCool: I think "wot-architecture-1-1" is better
... what did the JSON-LD spec do?
... is there a convention?
<kaz> JSON-LD uses https://www.w3.org/TR/json-ld11/ for their 1.1 version
... and different groups use various notations
... TTWG uses https://www.w3.org/TR/ttml-imsc1.1/ for IMSC 1.1
... ARIA WG useshttps://www.w3.org/TR/accname-1.1/ for "Accessible Name and Description Computation 1.1"
[Day 1 adjourned]