- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 15 Feb 2019 15:15:26 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
https://www.w3.org/2019/02/13-wot-minutes.html
also as text below.
Thanks a lot for taking these minutes, McCool!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-IG/WG
13 Feb 2019
Attendees
Present
Kaz_Ashimura, Dave_Raggett, Matthias_Kovatsch,
Daniel_Peintner, Kunihiko_Toumura, Michael_Koster,
Michael_Lagally, Michael_McCool, Taki_Kamiya,
Tetsushi_Matsuda, Tomoaki_Mizushima, Toru_Kawaguchi,
Zoltan_Kis, Sebastian_Kaebisch, dsr, Ege_Korkan
Regrets
Chair
Matthias, McCool
Scribe
McCool
Contents
* [2]Topics
1. [3]Agenda
2. [4]Scripting
3. [5]Quick updates
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<scribe> scribenick: McCool
Agenda
updates to org to be distributed via W3C marketing; IG renewal,
updates to chairs and affiliations
Scripting
Zoltan: security section on runtime in arch docs
<zolkis>
[8]https://github.com/w3c/wot-scripting-api/pull/155#issuecomme
nt-442830910
[8] https://github.com/w3c/wot-scripting-api/pull/155#issuecomment-442830910
Matthias: definitely does not belong in TD
... can it be extended to other scripting
... can it be generalized?
Zoltan: yes it can be generalized
Matthias: if it can be generalized, arch is a good place
... but maybe more implementation guidance
... notions of provisioning, etc. are there as well, don't
belong in scripting
... if too long compared to other content kind of awkward
... would be good to move into a branch
McCool: elena did this PR, she probably has to do the PR reorg
Matthias: ok
Lagally: would be good to have final cleaned up text in a pr
Zoltan: the text is good, it's just the discussion about where
it goes
... is a pr is both places
McCool: pr in scripting is to remove things from scripting that
we wanted to move to arch
<zolkis>
[9]https://docs.google.com/presentation/d/1HN15VhjCcZEjrSllFSUV
xUWiYhxFdslx80EtyJObNeo/
[9] https://docs.google.com/presentation/d/1HN15VhjCcZEjrSllFSUVxUWiYhxFdslx80EtyJObNeo/
McCool: but can leave the PR for now and reorganize it
Zoltan: sharing slides on examples for new scripting API
<mlagally__> mlagally: we wait for a new security PR against
the architecture doc and don't consider the current one
matthias wanted to get some clarification
Matthias: want to have concrete reasons for each design
decisions
... felt that information was missing
Zoltan: did you see the design document? That was the main
driver
Matthias: it would be good to summarize the reasons in the
slides
... for example, why are there constructors that are not used?
Zoltan: but they are used...
... today, before this meeting, got some comments from kenneth
... he had some issues with "getting" event names
... since events happen, you don't "get" them
... matthias was asking about integrating with fetch standard
... but looks very complicated
Matthias: fetch is just there to get a document
Zoltan: but then we have to add a section to explain how to use
it
... but you seem to agree with ben that we should use document
fetch
Matthias: but everything was removed from the wot object except
fetch
Zoltan: that is true, but where else would be put it
... anyway, we got that comment
... another issue, programmatic TD specification
... this is a separate use case
... takes a lot of boilerplate
... just for creating a JSON document out of JSON object
... it is very long, as long as the TD spec
... do we have this use-case justified, and is there an easier
way?
... the question is, do we want to stay with the node API, or
make it W3C compatible
McCool: I don't know why we can't just create a JSON object and
validate it
... that would be a very simple API
Zoltan: there are a lot of issues with type conversions and so
forth
<Zakim> dape, you wanted to maybe we can even leave out "fetch"
in general from scripting
Daniel: not opposed to make some changes to move towards
browser
... moving towards browser, but don't have support from browser
vendor
... if they tried to implement it they would have further
changes
... so we are not sure we are filling their needs
... we would need a lot more feedback from them
Zoltan: that is why I made these side-by-side changes
... it is not that many changes
... is it just a style thing?
... personally I think the change is not that much, just style
Dave: want to respect the tag's opinion
... but they may not reflect those of the browser vendors
... we should also be reaching out more broadly to dev
community
Zoltan: I also asked (?name) who is a member of the node
community
Dave: different communities as well, node, web devs, etc.
... maybe we need more than one api
... but we really do need to reach out
Zoltan: sure; how do we do it?
Dave: well, the usual things, blogging, etc.
... I don't think a simple questionnaire is enough
... people need to try it
Zoltan: so maybe we don't standardize things yet, we should do
oss implementations first
... so are aligning with mozilla that we should not really
standardize this
Dave: at least we should reach out more broadly
Zoltan: so node-wot would not be an implementation of a W3C
spec
... how do we position the current API?
Matthias: central issue is that no structure to the problems we
have
... need to better structure issues, resolutions
... also, scripting API is not a standard, just a note
... we have failed to come to a consensus on this
... but good to at least have a note that captures what we have
and the design decisions for them
... at TPAC we decided to document what we have now
Zoltan: so, what is the next step?
Matthias: need some clear consensus on group that we are not
doing a standard, just a note
... also important for arch document
... docs say we are just doing a note
Zoltan: yes, we agree on that
Matthias: a lot of people in this round were saying
"standardization", want to make it clear we are not doing that
Zoltan: what is not clear is what should go in the note
... one option is to make a note from the current content
... and use an interface description, not WDL
... if we go and make small changes, then can use WDL
McCool: maybe we should publish both, get feedback
... also, keeping current spec minimizes rework on node-wot
... we could then publish another spec with the new interface,
ask for feedback
Kaz: think there are 2 levels of problems here; policy level
and technical level; for the technical discussion, we've been
talking with Yves and PLH, also possible discussion during the
expected workshop; on the other hand, we need to talk about the
policy level, i.e., which way to go
... should happen before technical level discussion
sebastian: agree with McCool; have two notes
... one on current API
... get it published
... one other thing in charter is a "simple API"
... that would be more compatible with browser
... anyway, let's complete the current one, then spend the time
to target the browser
... that was my understanding of the outcome from Lyon
Matthias: two notes is not a good idea...
... release a low-level API that we can build on
... technically from what I know, using the current API as a
low-level API will be hard
... so something simpler would be better
... and zoltan's proposal is in this direction
... just want to see documentation of design decision
McCool: summary, prefer moving to the proposal from Zoltan, BUT
need to better document design decisions
... and don't think we should publish the current (complex)
spec as a note
Dave: have been working at Simple API...
McCool: what is a better basis? a low-level layer?
Dave: don't quite want to prejudge right now, but agree a
low-level base layer is probably better
Zoltan: ok, let's follow up in scripting call
Matthias: one final point, since it is a note, we don't have to
do testing, validation, etc.
McCool: this information is in the minutes, but should probably
be in the wikis
<dsr> Just for the record, I want to explore things as property
values in the high level API
Quick updates
<Zakim> kaz, you wanted to make some reports :)
Kaz: quick reports
... I've been attending the W3M meeting
... and the workshop has been approved, yeah
... also mentioned a proposed subtitle, "an open web to
challenge IoT fragmentations", during the call, and got a
comment to say "fragmentation" instead since it's uncountable
... note possible change to the workshop date
... currently 27 May-29 May but 27th is a bank holiday in the
US
... so Siemens is looking at option to move the event a bit
... have not gotten feedback yet on that
... when hear, will let people know
... also IG extension announcement was sent to the AC list
... finally, would like to wrap up the f2f minutes
... please review, would be good to wrap up next week
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [10]scribe.perl version 1.154 ([11]CVS log)
$Date: 2019/02/15 06:11:59 $
[10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[11] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 15 February 2019 06:16:28 UTC