Ever wondered how you might implement "Hello World" in a non-domain specific language such as in the roots of Oslo looks like.........(I found a snippet from one of the PDC Webcasts....)
(This is written in a tool/shell that ships as part of the Oslo SDK - Intellipad)
The left hand side is the instance document; the middle is the grammar or transformation; and the right is the Output Graph.
This is a pretty specific sample - as in fact its very specific and only takes one input - "Hello World" (as dictated on the syntax line)
What's so special about all of this?? I hear you ask.....
There's a huge amount of power in being able to 'model' your world/data and relationships. Today we're pretty comfortable with XML but we also have to tolerate things like parsing '<' or attributes etc. Or if you've ever been given a schema full 100s of fields when you needed to use just 5. XML is not perfect, but it certainly has its need.
Storing this sort of XML in the DB I think is painful at best, while SQL 2005/2008 goes part way towards helping us, there's still a bunch of specifics that the DB needs to know about the XML and if that Schema changes, then that change goes all the way to the DB....otherwise the alternative is Tables/Rows/Columns + invest in Stored Procs to manipulate the data.
Enter the Modeling Language -M
We can basically define our world - if you're dealing with a customer with 5 attributes, that's all you specify. You could take your V1.0 representation of a Customer and extend it etc etc.
Deploying the model is deployed straight to the Database (known as a Repository) - the deployment step actually creates one or more tables, and corresponding Views. Access is never granted to the raw table, only to the View. That way when you extend or upgrade your models, existing clients see just their original 'View' keeping the new attributes separate.
So in terms of building a model of the information your systems are utilising -> 'M' is a very rich language, which decorates and defines a whole bunch of metadata around your needed entities.
Digging a little deeper into M.... we have 3 main defining components:
1. M-Schema - defines the entities + metadata (e.g. unique values/ids etc)
2. M-Grammar - defines the 'Transformation'. How to transform the source into the output. You could loosely look at this as: Y=fn(M) "Y equals some Function of M"
3. M-Graph - a directed graph that defines the output (they use directed graph to indicate through lexical parses, that something has a start and definitely finishes.This is a check the compiler will do)
You'll notice at the top of this shot, there are DSLs - these are Domain Specific Languages. e.g. a language full of terms and expressions to define for e.g How to work with You local surf clubs competitions; another could be How to Manage and describe Santa's Wish list.
You might be thinking....I go pretty well in C#, why should I look into M?? C# is obviously a highly functional language that when you start coding you've got all the language constructs and notation under the sun at your disposal - decorations are done through attributes on methods/classes etc.....but modeling something still in done in a pretty bland way e.g. structs, classes, datasets, typed datasets etc. You're starting with a wide open language that really without you creating a bunch of classes/code doesn't have methods like Club.StartCarnival.....
M - take what you're describing, a carnival and model it. What entities are in a Carnival (people, lifesavers, boats etc) - model this - give us a picture of what they look like (data you'd like to hold and the relation ship), define a grammar (words, constructs and operations) on how we can work with these entities - we now have a Surf DSL (that of course can be extended to V2.0....)
Developing solutions against the Surf DSL - the compiler knows all the defined commands, constructs and schemas (cause we defined them in our DSL). They're the only operands that you can use as a developer - this simplifies the picture immensely.
The beauty about M is that the DSL is simply deployed to a Repository (which at this stage is SQL Server, but could be any DB as we get access to the TSQL behind the scenes)
As I dig a little deeper I'll be illustrating with some samples going forward - hope you enjoyed this post....for now :)
Lastly - it's amazing that way back at Uni, I studied a subject called 'The Natural Language-L' (and it was one of those things where I thought - I'd never use this again....well guess what 15 years on....M is looking very close. How I even remember this is even scarier!!!) - the subject was language agnostic and dealt with what was required to create/specify a language that could be learnt, written and interpreted.
Cheers...'L'