<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> 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> 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]