[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Picking the Tools -- Marrying processing models to data model s
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@f...] 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|