Automotive Working Group Teleconference

<scribe> scribenick: ted

Fall F2F

https://lists.w3.org/Archives/Member/member-automotive/2019Apr/0001.html

Patrick: the Transportation Data workshop is now going to be held in September in California

<PatrickLue> TPAC 2019: https://www.w3.org/2019/09/TPAC/

<PatrickLue> 16–20 September 2019

<PatrickLue> Transportation Data Workshop in the week before TPAC.

Ulf: sounds better to have it in California

Glenn: second that
... having them in the same location

Magnus: TPAC would be good for me for my travel logistics

Harjot: no preference and go with the majority

Ted: anyone possibly able to host?

PatrickL: I'll check
... dates?

Ted: Will confirm with Uber on workshop, probably F2F 9,10,11

Pull Requests

<PatrickLue> https://github.com/w3c/automotive/labels/gen2

<PatrickLue> https://github.com/w3c/automotive/pull/303 Introduction

Ted: I have been learning more about W3C WebOfThings' template bindings https://w3c.github.io/wot-binding-templates/ which might be useful in supporting additional protocols

https://github.com/w3c/automotive/pull/302

PatrickL: need to communicate types efficiently, strings are strings, byte buffers and now buffer arrays but that is more a wording convention
... need to be succint with them as possible, send Uint8 goes to 255 for instance

Ulf: still want time to review

PatrickL: ok to postpone, questions though?

Ulf: align with VSS?

PatrickL: they carry forward, there are however predefined restrictions such as limiting to whole numbers from 0-255 aka UInt8
... no types removed, more shrinking down

Magnus: also didn't review enough and from my perspective it makes sense

PatrickL: will wait to give Ulf time to review

Laurent: I am noticing there are a couple copy/paste errors we need to fix just now and will do :)

<PatrickLue> https://github.com/w3c/automotive/pull/295

PatrickL: I gathered from the description of VSS there is an idea to solve the positioning issue and the description of filters aligns with those
... and inlined Peter Winzell's comments, believe this one is ready for merge. any questions?
... it is about making it possible to limit how much of the tree one wishes returned and introduced an easy way to describe the query
... we can revise later but seems like a starting point

<PatrickLue> https://github.com/w3c/automotive/pull/304 Simple Tree Elements

Daniel: I went through the others and didn't find blockers. for this one a bit confusing
... the language at the begining makes sense but then with names and ids, not sure how that will be mapped with VSS
... in the schema you referred to services which are not defined

PatrickL: this is partly from splitting apart my big pull request into disgestible pieces
... as such not everything is clear
... the idea with names was that they would more or less describe we could call type, a name could be something like tire
... to identify a specific tire we can assign it an id
... defining a tire suggests a schema

Daniel: also ask until tomorrow to finish reading these

Ulf: in VSS we have a naming scheme, should we have that in two places

PatrickL: plan is to support everything created there. I am trying to make it more descriptive in an easy to describe manner
... I went through the notes from last year, reviewed pros and cons from VISS and ViWi

Daniel: name would be tire, the id then path to tire
... if you say it is compliant then use the VSS notation and not mention the id

PatrickL: need something unique to address and allow for it to be something that can be generated automatically. it can be a string if available or autogenerated
... if you have a list of media tracks for instance that should be uuidv5
... I don't personally need the uuid but like there is a prescribed way of autogenerate something that is unique and uuid is a good match
... it can be a string as well

Gunnar: is it a string or is it represented differently

PatrickL: no you could send it more efficiently
... it could be full path for VSS string identifier
... it would be defined through the schema. transport channel may want a more efficient

Daniel: we have numeric id planned for VSS

Ted: we may want a reserved range for custom signal extensions

Laurent: uuidv5 is a 128bits and states how they are computed, you can generate them on a child of a namespace
... there are a concrete set of rules on how it can be generated and unique in a namespace

Gunnar: ok with that

Laurent: what I find missing in signal id database is how to tell if it changes its id
... how can we guarantee it persists across versions, need to be forward compatible

PatrickL: that would be a nice thing
... we are not at this point right now on how an id can be mandated by a schema to make it easier
... please look over the pull requests more and will bring in examples as Daniel pointed out and can discuss this in detail next week
... comments appreciated so we can resolve sooner

Gunnar: do you have another example of a data description besides VSS, ideally something used in practice
... it would help prove how it would work
... and strengthen case to have this description, make it less theoretical for alternate data descriptions

PatrickL: it was decided quite a long time ago to support alternate data models

Daniel: second the request

Gunnar: it would be a concrete mapping at some point so why not start looking at that a little bit now

Survey responses

https://www.w3.org/2002/09/wbs/76043/gen2data/results

Ted reviews survey and will send summary by email

Ted: what did you mean by "anything specific to a domain"?

PatrickL: doesn't fit question, more about avoiding mixing domains

Ulf: group has made clear their commitment to VSS

PatrickL: goal is to be compatible with what VSS created

Daniel: there were some wording improvements removing problem area and like where this stands

[adjourned]