OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Models and containers

[ Lists Home | Date Index | Thread Index ]

> 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

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

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS