RE: Is there a difference that makes a difference between topi
Thanks Lars. That is a good explanation. I understand that topic maps have many applications. The model you present starts from topic map. Sometimes, when building a data dictionary, one is both documenting an existing database and creating a metadata set for a query builder to that database. The database pre-exists so the initial extraction is likely to be something where one gets the tablenames from directory listings, then using native database platform calls, dumps out the useful properties (eg, field names, data types, widths, validation expressions if any, null or not null, and so on). By this point, one has a set of metadata tables and begins to add the soft join information (eg, lookups that don't rely on primary/foreign keys). Once one has that, the topic maps would be useful at the user interface, but the essential engine is still a Run SQL procedure tied to the names in the GUI controls that the user enters as they use the data dictionary to build the queries. At that point, the topic map is equivalent to the named query. So I see the use of the topic maps but it still seems to be almost a stylistic preference. I'm still not sure if it is better, worse, or about the same functionality. len -----Original Message----- From: Lars Marius Garshol [mailto:larsga@g...] * Claude L. Bullard | | The subject says it all. IOW, why use topic maps for systems that | have implemented a data dictionary? I would use topic maps to build the data dictionary. That would give you an extremely flexible model to represent your dictionary in, and one that could easily be connected to documentation, real data, and anything else you might wish. We recently did this in an XML project that was based on the ICH ICSR DTD for reporting side-effects of drugs. From the DTD (and the comments therein) we generated a topic map, using the DTD API of the xmlproc parser. From that topic map we then generated an RDBMS schema for storing the data, a Java object model for representing the data in applications, and an implementation of the object model that stores the data in the RDBMS. The last step was automatically generating a SAX importer and an exporter for the XML format. After we have built the user interface and the business logic on top of this we will have the scripts add in the RDBMS schema and the Java object model to the topic map, so that we can deliver the topic map to the customer as documentation. And that will essentially be a data dictionary, but one that's really been used. In any case, topic maps have *much* wider applicability than just data dictionaries. Your question is a little bit like asking "Why use XML for systems that are happy with TeX?" Well... BTW, you might also find this article enlightening <URL: http://www.xml.com/pub/a/2002/08/21/topicmapb2b.html > unless that's what made you ask the question in the first place. :-)
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