🚀 go-pugleaf

In article <BrrH56.1Bp@watdragon.waterloo.edu>, drraymon@watdragon.waterloo.edu (Darrell Raymond) writes:
> In article <1992Jul20.171350.1@idicl1.idi.battelle.org>, raudabaugh@idicl1.idi.battelle.org writes:
> 
>>I view SGML as a very powerful method to describe relationships between
>>entities within a document (or document type).  To suggest that SGML is
>>a poor data-modeling device seems somewhat absurd.  ASN.1 encoding is also
>>a poor data-modeling device so nobody uses it for that.
>>
>>SGML does an excellent job describing document structure.  BUT, it does not
>>address context/semantic relations that data-modeling is all about.  Nor
>>should it.
> 
>   I can't make head or tail of this comment.  If you "view SGML as a very
> powerful method to describe relationships", then why does it not "address
> context/semantic relations"?  What is the distinction that you draw between
> modelling and describing?  Is it that you think that structuring means 
> "identifying entities", while modelling means "describing relationships"?
> 

SGML does not describe the relationships between documentS (the S is very
important here, and left my S hanging).  Relationships in a document yes,
otherwise no.  Also, scratch what I said saying SGML models/describes
relationships in a document type, not true.

>>OK, why did I bring this up?  Because standards should be used for what they
>>are good for.  A good data-modeling standard that sits on top of a data
>>manipulation language (such as SQL) and a document description language (such
>>as SGML) would be heaven sent.
> 
>   A data model doesn't sit on top of a data manipulation language, just
> the reverse. The relational model came before, and is quite independent 
> of, SQL.  
> 
> -Darrell.

Agreed.  But the relational model as described by Dr. Codd's paper does not
enforce the absurd query I described, so SQL supports them (actually less than
would appear legit given the model set out by the paper).  Why?  No semantics.
Add some models on top of the relational model and yes, you get the semantics
(including several by Dr. Codd).

What I'm looking for is a way to sit relational data (or all you can get from
a CREATE TABLE command in SQL) and structured text (via SGML) side by side in
an agreed upon manner.  I also want interdocument integrity.

Also, to throw one more stick in the fire:

A DTD that describes a database can be built.  A DTD tha describe interdocument
(or intertable) relationships cannot be built, since that must allow for
recursion (EMPLOYEE.MGR_ENO owns EMPLOYEE.ENO comes to mind).

Aside:

We are importing SGML documents and relational rows and making them live
together and enforcing SGML relationships as well as relational relationships
in our current project.  However, this is has been VERY seat of the pants and
very educational to our SGML guru (NOT ME) and our relational has-been (me).
SGML docs do not take kindly to being normalized, so don't.  Instead, be
creative, thats what we've found.