A Basic Object Definition Language

Here is a rough cut of ODL along with comments. This is very much a work in progress. Now that I have a meta-grammar and a concrete syntax for describing languages, I can start to write the languages I have been playing with. I will then build up to those languages in the framework so that the framework can consume metadata that can be transformed automatically from ODL, allowing for the automatic generation of most of my code. Expect to see BIG changes in this grammar as I combine “top down” and “bottom up” programming, write some real world applications and see where everything meets in the middle!

Most importantly, we have objects that are comprised of 1..n attributes and that may or may not have relationships. This is the high level UML model kind of stuff. Note that ODL is describing functional metadata, so an object would be “Article” – not “ArticleService” or “ArticleDAO” which are implementation decisions and would be generated from the Article metadata automatically.

Concepts:
Object ::= Name [ShortDescription] [Description] [“extends ” Object.Name] {Attribute} {Relationship}
Attribute ::= Name [ShortDescription] DataType Required
Relationship ::= RelatedObjectName Required Multiple Composed

Attributes:
Object.Title: The title of the object: text(100)
Object.Name: The name of the object: text(100)
Object.ShortDescription: A short description of the object: text(250)
Object.Description: A full HTML description of the object: ntext
Attribute.Title: The title of the attribute: text(100)
Attribute.Name: The name of the attribute: text(100)
Attribute.ShortDescription: A short description of the attribute: text(250)
Attribute.DataType: Some kind of data type to describe the attribute. Could be simple primitives like text, int and datetime, or could support custom data types (I’ll get into those in a moment).
Attribute.Required: Whether the attribute must have a non-zero value for an object containing it to be considered valid: Boolean
Relationship.RelatedObjectName: The name of the object the relationship relates the primary object to (if relating users to companies, this would be “Company”): Must be a valid Object.Name: text(100)
Relationship.Required: Whether at least one object must be associated to the relationship (a customer must have at least one address – Required = yes) :Boolean
Relationship: Multiple: Whether or not multiple objects can be associated to the relationship (a company has many employees - Multiple = yes) :Boolean
Relationship.Composed: Whether the related object is a composed object that should be destroyed on its parents deletion (Grade is owned by student – if you delete the student you may want to delete the grade as long as it isn’t required for reporting purposes - Composed = yes) :Boolean

Don’t focus on the details right now – this is just a very rough sketch. But we’re starting to sketch out a system for describing and generating a database schema and a set of model components.

Note that I’m distinguishing at this level between a relationship and an attribute. A relationship relates an object to another object whereas an attribute relates an object to a single data point (anything from an int to a SSN, but not a company or an article). This is a pretty standard approach to OO design. Coming from a higher level you can now see quite clearly that this is actually an artificial distinction, as a relationship is really just a special type of attribute where the data type is an object – not just a primitive or custom data type. It is also interesting to note that given that both primitive and custom data types have behaviors as well as state (think of java string methods), they are also kinds of objects. I would define a primitive or custom data type as an object that can only have one attribute.

This is all kind of interesting, and it raises the question: “would there be any benefit in modeling an object as having only attributes (where relationship = special type of attribute where data type = object)”? Hmmmm.

I think I’m going to look at that question in a separate posting. Then I’ll come back to the ODL and start to clean up some basic limitations (right now it doesn’t have any way to distinguish persisted from calculated attributes, so you can’t generate a db schema, so that is going to be one of the first things I’m going to add).