VISS Base vs. Extensions

[erikbosch]

In #381 and #382 it is discussed if certain parts of VISS should be optional. Would it be an idea to have a generic concept/syntax where certain parts of VISS can be specified as mandatory (base functionality) while others are specified as optional extensions. Somewhat similar to https://en.wikipedia.org/wiki/RISC-V#ISA_base_and_extensions

That could possibly be useful for the future when organizations start offering VISS implementations to possibly customers (both clients/applications and server-solutions) to have a common language to describe what is supported. E.g. a syntax to specify that a VISS server implementation for example supports Authorization and PathFilter but not CaptureFilter

[petervolvowinz]

What would be the merits of a special syntax in this case. I think it is pretty clear what is optional and what is not ? You just add optional to the paragraph ? I my view this is overcomplicating things.

[SebastianSchildt]

Marking things as "optional" (or/and mark "core/essential") definitely is the most important step.

In my opinion an important point and takeaway from Erik's suggestion is, that our model should be: There is "base/essential" required feature level, the rest are understood as "features" that can be (more or less) mixed and matched as people require (which is in line with the RISC V ISA model), and not a set of "Feature Level 1,2...3" where every level bundles a fixed amount of features. That would lead to endless discussions :) Probably the market will show what are useful "feature sets".

For practical purposes it might be useful to have something like a "capabilities" query, which returns a nicely formatted JSON or text string listing supported features in a machine readable way..

[erikbosch]

Syntax is maybe not the right wording, I was more thinking if it would make sense to have some form of identifiers for the optional parts/capabilities, so that you cay something like "Our product X supports the following optional capabilities from VISS: AAAA, BBBB and CCCC, but not DDDD". But the section headings of the optional parts could possibly suffice for that purpose.

[UlfBj]

I agree with what has been said above. So the next step would then be to

1. exactly specify what should be optional (all not optional is mandatory).
2. Decide how a client queries the server on its capabilities.

I would propose that 2. is solved by using the "static metadata" request that the spec supports (CORE ch 7.4), by adding "server-capability" to the list of supported key names. An HTTP request would then look like below. GET /Vehicle?filter={"op-type":"metadata", "op-value":"static","op-extra":"server-capability"} HTTP/1.1 The outstanding question would then be how the server expresses its capabilities? Maybe the different optional parts in the spec can be tagged (shown in the spec), and the server then replies with a list of the tags that are supported?

[UlfBj]

Fixed in PR#437