# Data type regulation policy and membership fees **URL:** \ **Category:** Development & Maintenance\ **Created:** [December 8, 2019, 6:55am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707 "2019-12-08T06:55:57Z")\ **Posts on this page:** 8\ **Page:** 2
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 2, 2020, 9:38pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/21 "2020-05-02T21:38:43Z")
I think the following would be a nearly equivalent restatement of your proposal: you suggest to _introduce a new namespace under **`regulated`** dedicated to data types that are considered sufficiently stable and generic to be recommended by UAVCAN maintainers for cross-domain use._ When you say that such types have to be developed by expert working groups, that seemingly implies that the types have to survive early testing somewhere outside of the regulated set. Following the example of vendor-specific [CSS extensions](https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefix), we could combine segregation by device class with segregation by the vendor. I think this model would be easy to explain to everyone who has at least cursory familiarity with CSS. Suppose we retain **segregation by owner** as described in my previous post and introduce an additional namespace for such expert-defined namespaces, which we could name `regulated.endorsed` (a shorter name is needed perhaps because we’re limited to 50 characters per full type name but I couldn’t come up with a better word yet). Once a particular namespace is deemed adequate for inclusion into the endorsed set, it is either moved there from an owner-specific namespace such as `regulated.px4`, or just symlinked directly. The idea of introducing base types first also seems very sensible and can be implemented here as well, such that the endorsed set supplies only the most vital functions, and owner-specific types can extend it as necessary. The endorsed set can also subtype its own definitions to support different degrees of generality, such as in your BMS light/heavy example. Should we keep going in this direction? I’m not sure I agree with the GetInfo idea because a single device may implement multiple profiles. We could allow devices to report several profiles at once but it seems like another major can of worms that is perhaps best kept sealed until some other day. **Edit:** the scope of the endorsed set should extend beyond just standard function nodes and also include common concepts that are frequently referenced in various robotic and vehicular systems, such as various mechanical conventions (e.g., twist, pose), electrical conventions (e.g., DC power), optical (e.g., camera image, point cloud), and so on, that are not necessarily grounded to a particular piece of equipment. **Edit edit:** in line with the above idea we may consider moving `uavcan.si` into `regulated.endorsed.si`. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [May 5, 2020, 6:34pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/22 "2020-05-05T18:34:45Z")
I don’t like “endorsed” because it will be strange to have deprecated types under endorsed in the future but we don’t want to change the namespace when a type goes into deprecation. Similarly, when we have multiple versions which version is “endorsed”. As for the need to “bake” APIs, I agree this is a great plan but to get the standard started we should allow a v1 set of types that are proposed by experts but which are allowed before field-testing. As the standard sees greater adoption and deployment we can improve this process for future revisions of the types. Regardless, it seems from your response that you do not like my proposal as presented? ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 5, 2020, 7:50pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/23 "2020-05-05T19:50:02Z")
> [@scottdixon](#): > > it seems from your response that you do not like my proposal as presented? I think what you described makes sense, I merely attempted to generalize it further. I think there might be cases where segregation by device class only might lead to undesirable over-specification. Consider a battery management system. The key reported property here is the amount of energy available in the battery which is used for the endurance estimation; the kind of the energy source is in most cases irrelevant for the consumer. Similar messages can be applied to other on-board energy sources beside batteries, from fuel cells and turbogenerators to nuclear reactors. In this case, one might want to abstract the core _physical process_ (power delivery) away from the particular means facilitating it (battery, turbogenerator, fuel cells, etc). Under that example, the namespace that segregates definitions by the type of the physical process would define a message containing a few fields like the timestamp, current, voltage, available energy, and the total energy. A message specific to a battery-electric vehicle (like a typical light UAV) would inherit from that and add BMS-specific fields like cell voltage and so on. Another message specific to a turbogenerator would add RPM and fuel levels, etc. Thus the name we chose for that sub-namespace should be generic enough to allow for different segregation criteria. If `endorsed` doesn’t fit, we could consider `regulated.uavcan` unless there are other proposals. Am I making sense here or did the conversation drift too far from the original goals? I think the key problem with the _segregation-by-vendor_ approach is that some adopters might be reluctant to rely on definitions authored by some other parties for various non-technical reasons. I suspect that a particular open-source autopilot team might be particularly hard to persuade to adopt data types residing under the namespace named after another open-source autopilot project, if you catch my drift. By endorsing particular well-established interfaces we could act as a mediator here. This is not even a technical problem we’re solving here, if you look at it this way. ---
**Author:** ![scottdixon](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/scottdixon/32/39_2.png) [@scottdixon](https://forum.opencyphal.org/u/scottdixon)\ **Post date:** [May 5, 2020, 9:01pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/24 "2020-05-05T21:01:26Z")
> [@pavel.kirienko](#): > > I think there might be cases where segregation by device class only might lead to undesirable over-specification. Any scheme will be subject to the infallibility of humans but the class-based scheme, as proven by USB itself, allows for mistakes to be corrected by defining new classes and deprecating old ones. For your BMS example, the type could have a _concrete_ baseclass that is generic. Certain systems would only require/consume generic BMS subjects but more specialized systems could extend this type to require more advanced subjects be present. I’m fine with `regulated.uavcan`. I think we discussed this in the past but thought that having `uavcan.foo` and `regulated.uavcan.foo` might be confusing however I think this is tolerable. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 5, 2020, 10:18pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/25 "2020-05-05T22:18:10Z")
> [@scottdixon](#): > > Any scheme will be subject to the infallibility of humans but the class-based scheme, as proven by USB itself, allows for mistakes to be corrected by defining new classes and deprecated old ones. Are you saying that there may be classes that describe more abstract entities than a particular type of device? For example, may there be a class for “power delivery”, which could be further specified as “battery power delivery” or “fuel cell power delivery”? > [@scottdixon](#): > > For your BMS example, the type could have a _concrete_ baseclass that is generic. Certain systems would only require/consume generic BMS subjects but more specialized systems could extend this type to require more advanced subjects be present. Yes, that’s exactly what I meant. > [@scottdixon](#): > > I’m fine with `regulated.uavcan` . I think we discussed this in the past but thought that having `uavcan.foo` and `regulated.uavcan.foo` might be confusing however I think this is tolerable. Seeing as neither of us are quite happy with the name, we should keep this question open for now, having `regulated.uavcan` as the fallback option. ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 14, 2020, 6:08pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/26 "2020-05-14T18:08:54Z")
To recap today’s call: @lorenz.meier believes that the policy of _segregation by owner_ may cause issues because the adopters will probably fail to recognize the interoperability benefits offered by UAVCAN. He is in favor of _segregation by application domain_, where the problem of limited expertise is to be addressed by well-organized working groups. The two approaches do not necessarily have to be mutually exclusive. A (sub-)namespace proposed by a vendor could be symlinked directly into a domain-specific namespace as necessary. FYI @scottdixon. ---
**Author:** ![VadimZ](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/vadimz/32/434_2.png) [@VadimZ](https://forum.opencyphal.org/u/VadimZ)\ **Post date:** [May 19, 2020, 7:29pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/27 "2020-05-19T19:29:02Z")
This a somewhat half-baked idea, but maybe I’ll throw it here: How about allowing type definitions to be “content addressable” by hash, similar to what [unisonweb.org](http://unisonweb.org) is doing for code ? This way vendor A would should have no qualms in copying the type of vendor B, calling it a different name but still be interoperable. (this this doesn’t address the issue with structurally identical types with different semantics, but maybe this can be resolved by a very minimalist list of “compatible types” rather than screaming all over the codebase “I’m importing competitor’s code”) ---
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [May 21, 2020, 4:24pm UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/28 "2020-05-21T16:24:40Z")
Unison is an interesting thing but I can’t immediately see how its ideas can be applied here. For now, we decided (at yesterday’s dev call) to adopt the _segregation by application domain_ where the issue of competence is addressed by the dedicated [UAVCAN Drone SIG](https://forum.opencyphal.org/c/sig/drone-sig), which may be followed up by other SIGs in the future. We are going to see if it works out or not. [Previous page](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707.md?page=1)