bmcweb/docs/OEM_SCHEMAS.md

13 and can be maintained forever. Within OpenBMC, we have no such group of
15 entire project.
17 Because of that, OEM properties in an open-source project pose many problems
20 OpenBMC's external Redfish API aims to be as compatible between systems as
21 possible. Adding machine-specific resources, properties, and types defeats a
22 large amount of reuse, as clients must implement machine-specific APIs, some of
23 which are likely to overlap, which increases the amount of code overall. OpenBMC
25 and therefore needs to take care when adding new, non-standard APIs, given the
28 In the experience of the project, OEM resources trend toward a lower level of
29 quality and testing than their spec-driven alternatives, given the lack of
33 implemented in projects that OpenBMC isn't aware of.
35 If a given feature eventually becomes standardized, OpenBMC OEM endpoints now
40 DMTF has many more Redfish experts than OpenBMC. While the bmcweb maintainers do
62    possible, message the new feature through the normal openbmc communications
63    channels to ensure OpenBMC is properly represented in the meeting/forum.
65    for change requests, and get your schema changes standardized; While OpenBMC
70    to OpenBMC", proceed to write an OpenBMC design document about the new
71    feature you intend to implement as OEM, under the OpenBMC (generic to all
73 4. If OpenBMC feedback is that this feature is specific to a single OEM or ODM,
82 the same level of quality as non-OEM.
86 The OpenBMC project maintains OEM schemas within the OpenBMC namespace, which,
92 namespaces shall be considered reserved: OpenBMC '''
94 To avoid versioning complications with clients, schemas within the OpenBMC
99 <https://github.com/openbmc/bmcweb/tree/master/static/redfish/v1/schema>, the