MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]