If there's one thing I hope that anyone would agree with here, it's that there is a compelling use for something which implements the design goals. There is an identifiable 'data logic' layer to almost all the software we write and the instruments we design; actually identifying and specifying that layer would in itself be a useful exercise. Exploiting and centralizing that logic in software components would simplify and improve our data handling software and our data management in general, from instrument through to release. There are other possibilities besides what I've been prototyping.
If we can identify a single place to add implementations for our data handling logic, again, the 'ATD business logic', then others can share those implementations and handle those data. For example, if someone writes a run-length encoder for compressing radar fields, then RLE compression can be specified as part of the model. Any field model which benefits can specify it, and any software using the software layer can interpret the model and decode the data. There will always need to be extensions, usually ATD-specific extensions, and there's no reason they should not be formally identified and implemented in one place.
XML has a very rich library of options which could be used to describe data models, like XML Schema. XML databases are becoming popular. Even CDL or the netcdf XML counterpart. The point is that more focus be given to formally defining data models and using them to ensure the consistency of the interfaces they represent. We should establish the policies and capabilities which we need in our 'data logic' layer and start to implement them in a software layer where they can be shared, maintained, and kept meaningful.