Subject: RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded
Yep. As a guy sitting here tediously updating a police records management data dictionary with 292 tables and 5992 fields, I concur. I made those distinctions during the CALS era when we got wrapped around the axle of OOPisms. We tend to forget that data objects have data types but not methods and that is why they scale. Plot o Data objects in the X. o Methods/functions/processes in the Y. o Users in the Z. If you can plot that in real time, or at least keep it in a mental picture, you can visualize the clustering of interoperable applications as they emerge. Essentially, X scales infinitely, Y barely scales at all, but couples to Z and Z to X. That effect is why XML won, a scalable web app has to be generic, and a local application (aka, situated) does not have to scale. The problem is getting people to understand that the high dollar value which can be sold or traded on is in the business rules in first-order-logic, not in the data dictionary per se. Of course, one needs both, but the data dictionary is a lot simpler to port than the rules. So a forms approach makes sense but between the presentation and the data objects sits a very expensive set of logic that is more local than the data. Getting the point across that 'systems interoperate; data is portable' is 90% of the battle in service oriented architecture design. The remaining 10% is the mythInformation amplified in the web about names and locations. len -----Original Message----- From: Ham, Gary A [mailto:hamg@BATTELLE.ORG] Len, Thank you SIR!!! I have always been uncomfortable with the term "interoperable data." Data does not operate in the first place, so how can it interoperate? But it can be "portable" which allows (but does not ensure) system interoperability. On the forms question, I have always felt that forms were a presentation/capture style for data, as opposed to data themselves. Building a data structure based solely on a form restricts its reuse in multiple formats. This is why relational data bases seldom are structured in the same manner as the input forms (or interfacing file systems) that are used to populate them. To say it another way, both form and substance are necessary, but do not confuse them. They are not the same.