[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Picking the Tools -- Marrying processing models to data model s
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Jeff Lowery <firstname.lastname@example.org>,"'Simon St.Laurent'" <email@example.com>
- Date: Tue, 22 May 2001 15:11:30 -0500
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".
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Jeff Lowery [mailto:firstname.lastname@example.org]
> 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