Microsoft provides an XML parser with IE 5.0 (and provides one as part of the operating system with Windows 2000). We can use this parser to parse an XML file. Thereafter, nodes in the XML document are readily available through a rich object model that mirrors the underlying data. This object model is usable from inside any ActiveX environment. We can readily write code that can read and write an XML file using this object model.
As with any hierarchical data, it is of paramount importance that data written out or read in is viewed in context. For example, consider the following XML data:
<transaction> <item_name>echo</item_name> <price>10000</price> <transaction> |
The price is valid only in the context of the transaction node. This is a very simple arrangement but when writing a complex schema, is prone to the introduction of several errors. When performing a write (or read), our code has to correctly remember the parent node (the nesting level) and so on. When XML read/write code is implemented in this manner, it is very difficult to maintain, as the data access code is intertwined with the XML read/write code.
One solution (actually the solution that we chose) that would help remedy some of this would be to have a parsed representation of an XML schema (or DTD) that can be processed by a system and then written out or read in with appropriate context information. The system would look somewhat like this:
The above representation can be reversed to perform a read.
Some advantages of using an approach like the above are:
The schema is effectively separated from the data. In other words, the code that performs the data access is logically separated from the code that is responsible for creating and reading an XML file. The two essential parts of this operation are thus separated. This allows for better maintenance.
It allows for one section of the code to be written independent of the other. When you can have the parsed representation of the schema available, the data itself could be populated from a variety of sources, each with different data access methods. The resultant XML would be the same and the code that deals with the schema would also remain the same. You can easily add other data sources as required.
We used this logical design as the basis for the implementation of our XML library. There is an XML map structure that is basically a parsed version of a schema/DTD. This is coupled with what we call a resolver object (this is nothing but a feedback interface for data gathering and feedback). Now that we have covered the basic logical design, we can look at some of the implementation details of this framework.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and Stingray, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.