VISS wrap up and Gen2 tree topic

Its time to wrap up VISS.

We have had several implementations, feedback on some of them including
implementation reports as we need to proceed to the next stage and a
minor inconsistency in the spec easily cleared up. There remains one
issue and that is a means to express what version of VSS is being
exposed.

https://github.com/w3c/automotive/issues/307

We agreed when VSS was being restructured that there should be a 1.0
release of VSS, separate branch to allow for continued edits, and to
call the next one VSS 2.0. My initial thinking was to have the version
returned by VISS within getMetaData. Gunnar suggested and I agree it
would be best as an attribute (version="N.N") on the tree root itself
and I raised that over on the VSS repo.

https://github.com/GENIVI/vehicle_signal_specification/issues/132

After that is accepted, I am inclined to update VISS and add something
about how the VSS version should be available at the root node of the
tree itself (or however we end up representing it) and if not present
to assume VSS 1.0 as that is what some people are doing in production
at present.

Once that is done, we should have a call for consensus and advance VISS
to Proposed Recommendation, next to last stage on W3C REC track.

This also relates to the current sticking point on Gen2 being meant for
a single monolithic and expanding VSS tree, accommodating various
additional domains.

https://github.com/w3c/automotive/issues/310
https://github.com/w3c/automotive/issues/306

and various other rescinded or approved pull requests although parts
are still contested.

I have made some other arguments against this single tree approach
favoring instead separate Gen2 services for additional domains. Can we
call something VSS 2.0 or give it any version if it has large branches
for additional domains? How can claim any version when the various
underlying branch structures are subject to change? We agreed a version
made sense to be friendlier to developers so they understand where to
find something in the tree.

Some who are in favor of single tree want it for the convenience or to
have clear relationships between the various domain data sources and
the vehicle. The latter can be solved with service registry which can
define those relationships and provide links to additional domain
services, each with their own domain specific tree. I want to discuss
registry as that can influence the thinking on this topic. Regarding
convenience, Ulf suggested on the last call that we make expanding the
tree optional. That can be done a number of different ways including a
transparent proxy to the external domain service. I can see that as
desirable but think we should address VSS version if random branches
are grafted onto it and should probably get into use of namespaces for
the domain branches.

-- 
Ted Guild <ted@w3.org>
W3C Automotive Lead
https://www.w3.org/auto