<scribe> scribenick: ted
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
<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
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]