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

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

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 
the relationship.

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

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


-----Original Message-----
From: Uche Ogbuji [mailto:uche.ogbuji@fourthought.com]


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,
etc.