[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: Uche Ogbuji <firstname.lastname@example.org>,"Orchard, David" <email@example.com>
- Date: Tue, 22 May 2001 13:19:59 -0500
Interface inheritance or code inheritance, Uche?
Interface inheritance makes one constrain the communication
model. That fits closer to the XML view of a world of
known message types or document types (someone really,
what IS the difference) or types that must carry their
definition packaged with them (SGML). Code inheritance
makes for an application that is initially very efficient
but over time grows brittle and side-effect ridden. Reuse
in the context of code inheritance is a limiting concept.
Yet even for the data, this same mirage of reuse occurs.
What can be #FIXED and what should be #IMPLIED or #REQUIRED,
even the bugaboo or element or attribute, reuse in data types
is also problematic. Thus all the weirdness of
architectures and element Elements. MMTT....
Perry isn't wrong, maybe a little elaborate. In effect,
a network of encapsulated nodes only says "all politics,
(policies) are local". Yet somewhere, predictability
and verifiability must become a consideration for reliability.
It must not only do something time after time, it must
do the same thing time after time or tell me exactly when
and what is to be different. Otherwise, we shake instead of gavotte.
To me, the benefit of XML is getting data design out of the
procedural design, yet I have never been able to design
a schema without some sense of how it is used; note I
did not say processed. To quote the Doctor: "Eventually,
somewhere, a bit must change state." so I am not belittling
the object-oriented designer. I am saying, his view of
how the data is to be handled and the user of the schema
may differ measurably. Where the schema names and structures
are oriented toward the authoring interface, a different
design is useful.
HLAL (High Level Authoring Languages) are designed to make
the author view of data the most important one. It isn't
that the author is KingOfTheWorld, he is just the one of
a series of agents that populate an n-dimensional dataspace
of time, name, content, and policy (a process control).
We don't design these with OOP objects in mind necessarily
because we may not want to demand a particular rendering,
or process. We simply want to capture information in
the metaphor most natural to the person.role doing the
job, then XSLT into whatever the objects need.
XSLT is key. The existence of the transform asserts
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Uche Ogbuji [mailto:firstname.lastname@example.org]
Reusability is one of the biggest lies of OO. I personally think that
code reusability is the philosopher's stone: it would be a source of
never-ending value, but there is the small problem that it doesn't exist.
There is nothing special about OO that makes code resuse magically easier.
The strange theory that inheritance is the key to object re-use is one of
the reasons I've heard for the insistence of some component models on
making inheritance part of large-granularity interfaces. This doesn't
lend any magic reusability to components than it does to class libraries.
The important thing is to focus on reusing data rather than code, and this
is a separate issue from whether the code is procedural, functional, OO,