Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Models and containers
 > > We tended to use repository to refer to the place where you > kept a model. > > Digital shipped a Common Data Dictionary for the VAX in the > early '80s. I don't > remember any integration with CASE or modeling tools at that > time. Later we used > repository as the container for models stored by products > such as Excelerator, > Application Factory, CorVision, and IBM AD/Cycle. > > The terminology difference might be a "which side of the > pond?" issue, or it > might simply be what software you were working with. I think the original theory was that a data dictionary would hold everything, then some vendors (especially RDBMS vendors) came out with products called data dictionaries that held a lot less, then the term "repository" was coined (by IBM?) to refer to the original concept of what data dictionaries were meant to be in the first place. In ICL we had a data dictionary product from about 1978 that held information in four quadrants: the upper half contained the conceptual process model and data model, the lower contained the processes and data structures as implemented. The other interesting thing about it (given that we're on an XML list) was that the data in the dictionary itself (i.e. the metadata) was controlled using a [meta]schema not unlike an XML schema, in that all the different kinds of data in the dictionary (e.g COBOL data definitions, relational table definitions, 4GL reports, screen layouts) were described using a BNF grammar. As with XML, this provided the means to describe a very rich fine-grained data model using a schema of only modest complexity, compared at any rate with an equivalent UML description. In effect, the dictionary was an XML database supporting a predefined but extensible set of about 250 document types. A COBOL record description, for example, would be one document type, a screen layout for the TP monitor would be another, and they were all richly hyperlinked. And of course, the schema language in which these 250 document types were described was itself one of the 250 document types. A number of companies, including ICL itself (with me as chief designer), tried to implement this kind of concept later using object databases and failed. I can't help feeling that doing it now with XML would work rather well. Of course the main advantage that ICL (like DEC) had in the early 1980s was that the whole product architecture was very coherent: we only had one DBMS, one TP monitor, one 4GL, one report writer, two or three 3GLs, one design methodology. That made the metadata much more manageable. Perhaps the most significant reason for the failure of the data dictionary dream was the end of vertical integration in the computer industry. Michael Kay 
|
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
|
|||||||||
