W3C home > Mailing lists > Public > public-wot-wg@w3.org > February 2019

[wot-ig/wg] minutes - 13 February 2019

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 15 Feb 2019 15:15:26 +0900
Message-ID: <CAJ8iq9V1HKG8TK9U_S5ubxOK_76hxer4L4Gg-DV9Cp52RULcjw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:52 UTC