Implement the Notifications data model (API) as an XML Schema using JAXB
Work-In-Progress
This page documents an idea, not a plan. This idea is not universally supported.
The purpose of this suggestion is to communicate more clearly that the core data model for Notification is a standard. Existing data sources, view strategies, and integrations are negatively impacted when that data model is changed. We need to make those changes only as a last resort, and to focus on designing, documenting, and leveraging a data model that is flexible enough to handle future use cases without breaking.
The Notification API will need to define a handful of entities. An entity, in this context, is just a set of persisted data. The notification API will use XSD to define each entity. The XSD will have the effect of creating a more concrete definition of the structure of each entity. It discourages future implementations from changing the external representation of the data without a compelling reason and it encourages developers to find ways to work with the entity as defined as opposed to modifying the core entity for every new feature. For this strategy to work, entities should be as flexible as possible. Extensibility should be supported using the existing Notification structure when possible rather than requiring modifications to the XSD.
The JAXB should be used to auto-generate the Java class definitions used by this implementation. This also makes it possible for producers/consumers of this service to regenerate the entity classes on their own. That means we don’t need to provide a separate jar for Java implementations, and it provides a workable entity definition that can be used in non-java environments.