CourtTrax maintains a proprietary, detailed XML Design Guidelines document that we make available to our Web Services customers during the design process. The following excerpt from this Design Guidelines document specifies the normalization/schema goals that guide our implementation of each new court.
| Standardize data as much as possible | Standardized data dramatically lowers the barrier of entry (development effort) for customers who use the service to expand their use of our web services product as the product itself expands in scope through new courts. |
| Data completeness | We make provisions in our data model for all court information and data relationships. We can't know in advance who will consume our data or for what purposes, or what data they will consider important. We strive to be as complete as each data source allows. |
| Graceful evolution | Despite our desire to come up with a complete data model, we know that we will inevitably discover new data and data relationships that will not make it into our Rev. 1.0 model. This process is carefully controlled to minimize negative impacts on trading partners. |
| Stable schemas for stable courts | When it becomes necessary to make additions to the base data model due to new data content of new courts, these changes should never impact the existing schemas for older courts that have not themselves changed. |
| Schema change notification for unstable courts | When the data provided by an existing court changes, we must begin providing the changed information and update the schema accordingly to meet the completeness goal. Our trading partners will need a way to find out programmatically that the expected data has changed. Schema versioning plan. When we are forced to change a schema for an existing court, a change notification will allow a trading partner to have an automated check for change before blindly processing data according to the old schema. However, trading partners will still have access to saved searches that were produced under previous schemas. We provide for the ability to know which schema version applies to an instance, and we keep back versions of schemas accessible. |