|
XmlObject - Adaptive Object Model |
|
Better Designs Faster |
|
XmlObject Implementation |
|
Frame Languages: I have not seen this mentioned elsewhere, but my advisor pointed out several similarities between Adaptive Object Models and Frame Languages. I feel that the XmlObject Framework’s use of XML makes this relationship even more apparent. The frame in Frame Languages refers to a container. A frame has a name, a frame has slots, and a slot can be another frame. To compare, an XML element has a name, attributes, content, and content can be another XML element. I was struck by the similarities. To take the comparison further, a frame has procedural attachments and XmlObjects have methods and both use inheritance as a means of organization. From the Wikipedia “Most frame-based knowledge representations use inheritance as the central inference mechanism. The frames are organized as a hierarchy with some general concept as the root frame.” This is almost verbatim what XML delivers. The XmlObject Framework derives most of its functionality from a system supplied XML parser. With a bit more work, it could have had its own (encapsulated) parser. This would have allowed the framework to hide the many XML centric methods and properties and made for a something that could have been much more Frame like. However, this by itself would not make XmlObjects equivalent to a Frame Language. Still, it is an obvious and interesting direction for further study. Adaptive Object Model Architectural Style: The most popular reference (by Google rank) for the term Adaptive Object Model is Joe’s Metadata and Adaptive Object-Model Page. On this site you will find a paper titled The Adaptive Object Model Architecture Style by Joseph W. Yoder and Ralph Johnson [Yoder & Johnson 2002]. This paper effectively and precisely explains what it is that makes an object model “adaptive”. This is a must read if you are serious about implementing your own Adaptive Object Model. That is where I was some seven years ago. A coworker and I were serious about solving a problem. The problem was inadequate requirements and a very short schedule. We had yet to discover the existing body of work, but my coworker was convinced that meta-data in the form of XML was part of our solution. By arguing the complexity of our data model (both relational and hierarchal) my coworker was able to sell me on XML and together we sold our coworkers. Several years passed and we had completed several object model implementations that encapsulated the DOM. We were both working for a new company and had begun writing our own parser for yet another project when we finally figured out how to create a custom parser by deriving from System objects. At that point the pieces started to fall together. It was shortly after that, that a reading assignment acquainted me with [Yoder & Johnson 2002]. Studying the examples Yoder presented, and the few other examples available helped me to notice something. Pretty much every example defined it’s own metadata and implemented its own custom parser. I knew that with effort, I could generalize our implementation of an Adaptive Object Model so that multiple applications could use the same parser framework. With XML providing the metadata the hope is that the framework might be more universal than the other examples out there. That framework is what this whole site is about. It is called the XmlObject Framework. The framework is an embarrassingly simple collection of classes that make use of some clever (or maybe not) object oriented programming techniques. This combined with some judicious use of reflection makes possible things that are simply amazing to this developer. The framework is implemented in C# mostly because my current development requires it. My understanding is that it would have been just as easy had the implementation been in Java. Below is a simplified class diagram for the DOM objects that the XmlObject Framework is derived from.
Note the references that are maintained, I can speak from experience when suggesting that there is some essential complexity involved [Brooks 1986]. The XmlObject Framework makes very effective use of these references for both structure and for navigation. This XML parser is arguably the most used and tested parser in the world. I feel fortunate to not have had to create it, even more fortunate to not have to test it. One last item of interest. Note that the System.Xml.XmlElement maintains a reference to a property called InnerText. This property is the text that one sees in between the opening and closing tags of an XML element. In the provided examples you will see very little member data in derived classes. I make it a point to use the storage that is available via this property. This is done for two reasons. The first is that it allows one to use normalization techniques, very similar to those of the database analyst, resulting in a very high quality data model. The second reason is very important, likely the single best advantage of the XmlObject Framework over other solutions. Underneath the XmlObject Framework is the XML DOM object model. This means that the XmlObject Framework can leverage some extremely powerful functionality virtually for free. For example XSD Schemas, XPath and XSLT. This would not be possible if one chooses to store data as member data in derived classes. Imagine trying to write your own XSLT processor? The following links will take you to pages that describe the implementation. Before getting into the descriptions, I strongly recommend getting one of the sample applications running in a debugger. Instructions are provided on the Download page. In my opinion, no text description can substitute for setting a breakpoint and stepping through code. · XmlObject Base Class Implementations · XmlObject Derived Class Implementations Hopefully these descriptions help you to understand the overall idea. From here I suggest going on to the Project List. There we can get a closer look at the framework from an application’s perspective.
|
