# 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:** 1\ **Showing post:** 4
**Author:** ![ka\_ru](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/k/94ad74/32.png) [@ka\_ru](https://forum.opencyphal.org/u/ka_ru)\ **Post date:** [December 25, 2019, 7:17am UTC](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707/4 "2019-12-25T07:17:34Z")
> [@Uavcan and raspberry pi](https://forum.opencyphal.org/t/uavcan-and-raspberry-pi/592/13): > > As explained in [Data type regulation policy and membership fees](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707), the idea is to enable vendors to collaborate on abstract, reusable interfaces in a well-regulated fashion. In the longer term, we will use regulated vendor namespaces (such as regulated.zubax) as a base to define standard vendor-agnostic profiles. Keeping such generic namespaces in one repository is necessary to reduce the risk of fragmentation and to simplify their maintenance. I don’t think the name of a namespace could prevent … “I don’t think the name of a namespace could prevent other companies from using it in their systems or products.” I think you are mistaken. A simple example. I need the types of RPM, MOTOR\_TYPE, MOTOR\_NUM\_POLE\_PAIRS, MOTOR\_Rr, MOTOR\_Rs, MOTOR\_Ls\_d, MOTOR\_Ls\_q, MOTOR\_RATED\_FLUX, MOTOR\_MAGNETIZING\_CURRENT, MOTOR\_RES\_EST\_CURRENT, MOTOR\_IND\_EST\_CURRENT, MOTOR\_MAX\_CURRENT, MOTOR\_FLUX\_EST\_FREQ\_Hz and so on. This is necessary for the normal operation of the FOC controllers. Do you think that a company producing controllers will use data types of another company? ☹ Never. --- _[View the full topic](https://forum.opencyphal.org/t/data-type-regulation-policy-and-membership-fees/707)._