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

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
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
(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.