https://www.w3.org/2018/10/TPAC/
zakim close agendum 7
https://lists.w3.org/Archives/Member/member-automotive/2018Aug/0000.html
[Ulf shares screen]
Ulf: I had merged the attribute
and signal branches, there is only one branch
... the signal id file has all the attributes listed with their
data
... we have attribute top node and another top signal
node
... in this next view you can see there are no separate signal
and attribute nodes but a top car node
... I also created a media branch following VSS resource model.
there is still a private top node branch per OEM
... you can see signal (green) type leaf notes and attribute
(red) together in this
... I introduced a new key/value pair for easy transformation
into alternate formats
... I chose function for key name and open to alternates
... the value portion of the pair can have actuator, sensor,
etc.
... within a signal node previously you could have a sensor and
actuator value pair or both
... sensor produces data, actuator data is consumed by a
transducer
... sense-actuator is a term for nodes that do both. for
diagnostic related data I thought this new function type could
be used to distinguish it from sensor/ actuators
... it resides on OBD branch
... rbranches are neither actuator nor sensor
... in the specification the term signal is heavily used, it is
applicable to all these different types
... when signal is mentioned in VSS specification it refers to
all four types
... this allows us to create new key/value without loosing
information
... after modifying the complete vspec tree, visible in github
as commit made but not pull request yet
... arguments in favor of this proposal: describing a node is
found as key/value pairs, whereas that was path based
previously
... path itself no longer needs to be parsed whereas all the
other data was contained in the node
... I find that preferable to mixing access paradigms
... two branches was the same in both previously. they should
have the same structure and do in this new solution
... if you want to retrieve metadata from several nodes under
the two parents you would need to parse two branches
... merging removes some branches which reduces footprint, not
that important but cleaner
... search involving attribute parameters would have to be done
using a query mechanism in next version of VISS
... before you had to do path and wildcards, now it would be
done through a query interface. a single search mechanism
instead of two
... arguments against this proposal: you can no longer use path
and wildcard, you will have to do queries
... earlier you could find the same terminology in multiple
sensor names and could group them in searches
... if there is value in being able to do that going forward it
can be done based on the node names
PatrickL: thank you, quite a bit
to process
... personally I like the approach, bringing more commonality
to how data is addressed
... the type doesn't matter so much as where it is being placed
which I think was one of your design goals
Ulf: I agree
PatrickL: Laurent and I have been discussing addressing and have a similar view on how to place things logically in an address tree (URI space)
Ulf: I bring metadata from path and put it into node itself
Laurent: path is still part of the metadata?
Ulf: no, it is just a handle pointing to a node
it is all contained within, path is just helpful for client
scribe: path can be useful for
organization and representation but also fine with arbitrary
identifiers
... I think anyone can see my fork on github and take a closer
look
<PatrickLue> https://github.com/UlfBj/vehicle_signal_specification
Gunnar: you spoke about the function having the value signal. have you not determined the type yet?
Ulf: I am considering signal higher level term referring to sensor, actuator etc
Gunnar: you now have to determine which type of these applies then to assign. you might want an undefined placeholder for when it is under development
Ulf: good point
Gunnar: hierarchy of the tree
path was useful for knowing the physical grouping, eg within a
door or engine
... but since some signals can be sent from more than one node
how best to handle? do we need to distinguish or accept a
signal
Ulf: hardware producing the data is of a specific type
Gunnar: how are you distinguishing?
Ulf: I am keeping the earlier
semantics in VSS, some might need to be reviewed
... none of that information should be lost
... I am for adding undefined
Gunnar: naming itself might need modifications as well
Magnus voiced support of the proposal by email https://lists.w3.org/Archives/Member/member-automotive/2018Aug/0001.html
[[To me this proposal makes sense since I can see a few benefits with it such as parsing, reduced tree size and filtering.]]
Ulf: what is the thinking of the group, should a pull request be sent?
PatrickL: I think there should be a new forked branch of VSS for v2 spec work we are talking about and keep the current snapshot for VISS v1
Ulf: I was also thinking about
the practicality and will propose that to Rudi
... and agree we need to preserve the old structure for those
depending on it
Gunnar: agree it is a bit incompatible and there should be two branches
<PatrickLue> https://semver.org/
PatrickL: we want to use semantic
versioning
... it contains major.minor.patch for versioning number
... whenever the first major number is revised, they know
compatibility is likely broken. minor should only introduce new
features
... patch is fixes that should not affect functionality
... we use this extensively and intuitive to developers since
this convention is used elsewhere
Ted: +1 and we should also ask Rudi to use this in making a snapshot of VSS
Gunnar: yes, good starting point
but we should discuss whether it should be done to VSS,
different from W3C spec
... they may evolve independently
... if you are adding new signals is that a patch or minor?
Ted: probably no need to do minor revision numbers per new signal but batch them up and when we want an identifier for a collection we ask Rudi or other maintainers to make a numbered release
[adjourned]