Re: TRM - Morbidity has set in, or not?

dawn wrote:
> If such a programming language
> has RDM as only one of several ways of modeling and working with data
> in large shared data banks, then the RDM loses the exclusivity it seems
> to demand, however. So, is the RDM sub model you mention one that is
> still the only way to view persisted data, or simply one way? For
> example, could XQuery (or similar) and SQL (or a better implementation
> of the RDM) function side by side in a language that works with large
> shared data banks without violating the RDM?

I don't know about XQuery (which is meant for XML values), but certainly most UIs are a tree view of data, of which a relational database can support many (different restricted views of the same data). However, updates to data need the same constraints as the database itself, so from that standpoint, the application is a node of a distributed database.

But for presentation, different languages make a lot of sense.

> > The programming language also needs a highly developed process model at its
> > core. The object oriented process model provides a good starting place.
>
> Agreed.

What is an "object oriented process model"?

> XML and JSON are indications that we might have moved beyond the
> simplest of forms for communication of bulk data between systems,
> however, as there is no need to put data in what-was-once-called-1NF
> for data exchange (and no one suggests otherwise, as best I can tell).

I'm not sure what would be so different now, and I don't really see that XML is an advance. I still see plenty of cases where comma-separated values are more than sufficient, and properties files (e.g. in Java apps) usually easier to read and write than XML configuration files. S-expressions are fine, rich structures, and date from long before the relational model.

> With more richness in the current RDM, are there any folks using it for
> data exchange, employing set processing commands for data and
> constraints, for example?

I don't think the RDM has changed radically; the richness derives from user-defined types which Codd identified very early, and from proper use of relation-valued attributes (RVAs). Beyond that, the tree structure of an XML document doesn't capture anything additional; it is, perhaps, better suited to naturally hierarchical data. But most of the XML I see in practice communicates (badly) either a graph, or relations (via ID/IDREF and cobbled-together versions of these). Date identified a simple XML encoding of relations.

Constraints and commands are different, but constraints should be carried with the data. However, this would require a standard language, for complex constraints not capable of being encoded with simple tags.

• Eric