Re: Draft Auto WG recharter

Gunnar,

Good points My wording was less than clear.  I should have said what is the relationship of the two?  Will RSI be its own thing?  Weill there be another moniker encompassing them all?   I am not implying by any means the weight of either.

That said RSI is more than a loose concept.  It is specification submitted by W3C member VW that is implemented in production.  Of course it is not a W3C standard at this point.

I look forward to discussing with the group.

Paul J. Boyes | INRIX | Director of Telematics and Standards - OpenCar  |  206-276-9675 | paul.boyes@inrix.com<mailto:paul.boyes@inrix.com> | www.inrix.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.inrix.com_&d=BQMFAg&c=QbuapHRvbn0JdC8vTVkPHg&r=PRAN7lum5Ra662QLho8LU3bhFjBvLXn3bBkFbW0Amjo&m=V5l0WXfOEJwhcE0JsN06mQ5SQhpXL-DuAuK3YcnTZoc&s=OqQVi_DcS5rv8or8hZdFvY0re6YF0Wl-_8okxrxOF0w&e=>

On Jan 28, 2018, at 11:40 PM, Gunnar Andersson <gandersson@genivi.org<mailto:gandersson@genivi.org>> wrote:


—With RSI subsume VISS?  Will they remain separate?  It is not clear
from the current draft.

I'm not sure if the question even makes sense to me.  If RSI "subsumed"
VISS, then I think you have yet some other definition of "RSI".  I've asked
repeatedly for a clear definition...  As far as I can remember and
understand a combination of responses, it's a loose concept basically like
this:    RSI ~= "The upcoming work needed to define a REST-based access to
vehicle signals, and to other services (and subsequent specifications coming
out of that)"

In my opinion "VISS version 2", is accurated for describing the further
development of the vehicle signals specification.  The other services remain
separate although will strive to achieve similarity.  This similarity will
be possible by separating the protocol from data definition, but I'm also
convinced we will realize that a "signal definition" (appropriate for
vehicle signals) and defining the operations provided by a service (for
navigation, media playback and other), might not always benefit from the
exact same type of definition.  But we'll find out as we go along, and of
course strive for maximum similarity.

So this is the work we all want to do but the abbreviation adds no clarity.
My proposal would be to drop the RSI moniker completely from this working
group because it doesn't seem to mean much.  If "RSI" only means
"REST/HTTP", write REST/HTTP so the rest of the world understands.  Let the
charter name clearly and directly name the intended services/functions to be
developed, and in so far it is already decided, the intended ways and
technologies (REST/HTTP).

If RSI means something else, please again try to answer with a definition
for my understanding (apologies if I missed something earlier, feel free to
reference).