Data model chapter updated in CORE doc. Message structure for supported protocols updated in TRANSPORT doc. #311
Conversation
…ed protocols updated in TRANSPORT doc.
…ed protocols updated in TRANSPORT doc.
…ed protocols updated in TRANSPORT doc.
…ed protocols updated in TRANSPORT doc.
| A composable node MUST be either a <a>branch</a> or an <a>rbranch</a>. | ||
| A leaf at the end of a <a>branch</a> cannot be decomposed because and will have an information stored in e.g. a <a>sensor</a>, <a>actuator</a>, <a>stream</a> or <a>attribute</a>. | ||
| A leaf under an <a>rbranch</a> MUST be an <a>element</a>. | ||
| The data model used in this specification is the <a href="https://github.com/GENIVI/vehicle_signal_specification">Vehicle Signal Specification</a>, version 2.0 (VSS 2.0). This data model uses a tree-like logical taxonomy to represent the vehicle data. An illustrative example of such a tree structure is shown in <a href="#tree-example">Figure 1</a>. For more details, see the <a href="http://genivi.github.io/vehicle_signal_specification/">VSS 2.0 documentation</a>. |
There was a problem hiding this comment.
if we use an external specification this must be final by the time we release our specification. can that be assured?
link to a specific version needed.
There was a problem hiding this comment.
The specification could point to a git tag URL if there is a definite version. I would say the tag would however not be locked down until we a nearing a Gen2 W3C protocol release, since there are some open improvement proposals.
Regarding when the VSS release is considered ready, it is quite a lot into the hands of the same people as are participating in the W3C work (for example the VSS maintainers are participating in the W3C automotive working group). In other words, the W3C working group could both evaluate the maturity of the current state to see if it is appropriate, and is also essentially responsible for the assurance of it moving to a labeled release.
| @@ -172,203 +162,27 @@ <h2>Data model</h2> | |||
|
|
|||
| @enduml | |||
| '> | |||
| <figcaption>Diagram showing an example tree.</figcaption> | |||
| <figcaption>Diagram showing an example VSS 2.0 tree.</figcaption> | |||
There was a problem hiding this comment.
are more data models available next to vss 2.0?
There was a problem hiding this comment.
In PR #311 it says that Gen2 uses VSS 2.0, so to answer your question, no.
In VISS it was mentioned that any data model that can express the address to a service using a VSS path expression, which in Gen2 is a URI expression, can be used. I believe that could apply here also.
There was a problem hiding this comment.
As a reminder, Gen2 per charter and past discussions is meant to be usable for other data models besides VSS. We only have one in front of us and while it can be used in spec as an example, need to make clear that is not the only one being supported.
There was a problem hiding this comment.
Actually I stand corrected, @danielwilms took a pass at representing media but within VSS. It would probably be better split out of VSS as a standalone. Gen2 could be used for additional data models defined elsewhere and not under one umbrella.
https://github.com/GENIVI/vehicle_signal_specification/blob/master/spec/Media/Media.vspec
There was a problem hiding this comment.
I agree with this - to split out of VSS . It raises potential other issues: One issue at hand is if the model needs to adhere to "...data model that can express the address to a service using a VSS path expression..." since this reflects the actual API definition making the data model in VIWI incompatible (basically) with the spec. How can we then allow for models other the VSS in this spec that are not a VSS path expressions ?
I think there are other use-cases apart from media where a dynamic model such as the one presented by VIWI are a much better fit than VSS, but should we really mix these in the same spec ?
There was a problem hiding this comment.
I agree that the rbranch and element node types in VSS is a bit confusing, it was introduced to enable porting of media data from VIWI. If that is not to happen, then it is probably better to scrap it.
The VSS 2.0 path is in my view a URI (segment delimiter instead of VSS 1.0 dot delimiter), so any data model addressing its services through URIs should be applicable.
There was a problem hiding this comment.
How can we then allow for models other the VSS in this spec that are not a VSS path expressions ?
In issue #306 we tried to come up with a theoretical way on how to do it. There was a request to come up with an example, but we never got there. I think media would be an obvious choice, because we talked about it a lot.
I think we should describe a supported taxonomy for Gen2 with a clear documentation on how to extend it (like private branches in VSS), as this is in my opinion a core asset the group can come up with and differentiate to other APIs out there, which try to achieve the same thing.
|
I find the rewrite of the Data model chapter introduction to be good. |
|
So, merging this one now. Issues can of course be raised to suggest further changes |
No description provided.