RE: [emergency] Groups - ICS-201-draft0.2.xsd uploaded

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

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.