RE: Picking the Tools -- Marrying processing models to data model s

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

Not at all.  That all representations are not alike 
is obvious.  Getting mammals to agree to use one 
of them in any context requires a political art, not 
an exercise in finding a technical truth.  Agree to 
one and go like hell.  But the day you make that 
agreement, you become The Man, and The Man is a 
bureaucrat, not an artist.

Groves. Ack... well many don't like the names and and and ...
back to the forum where the Citizens debate.

The highest truth is on the bottom of the stack 
if the test is "last man standing".

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Jeff Lowery [mailto:jlowery@scenicsoft.com]

 
> And yes, there is one of them [data model], albeit representable in a 
> thousand different ways, one of the worst ones being through 
> an OO langauge (as they currently are designed).


And I know what your next argument is going to be, Len, and that is not all
data model representations are alike. Yes! And I will even agree with you
that objects are probably the most a capable of describing all constraints
on a data model. But not all constraints are pertinent all the time, for if
it was so, what would be the point of XML Schema? (Wait! Don't answer that!)

So there is a subset of functionality, encapsulated within objects, that can
be easily shared with humans and machines alike if represented in a way that
separated it from the rest of the gobbleydegook of what makes up an
application.