Beyond announcements, visions, and rants: A living Domain Specific Language

R.I.P.

No, I won't go anymore into discussions whether x-first or y-first or nothing-first or whatever-first-or-second-or-last is a good way to model service contracts. The only thing I have to state is that sometime people sitting in the glasshouse should not throw stones. Everybody is free to choose the style of modeling technique and methodology that fits best. One party wants and needs angle brackets, another is just happy by coding objects, and yet others are fine the the latest-and-coolest-state-of-the-art-programming-model-and-runtime-that-does-x-first-in-a-revolutionary-way.
It is OK. Only the success of either approach approves either idea. Each to their own.

But what nobody can deny is that we will see a growing number of modeling efforts revolving around domain specific languages. While the scope of DSLs is very broad - we will see some very technical DSLs as well as very end-user- or customer-oriented-domain specific languages - we are still in the kindergarten of this brave new world (yes, I know that DSLs are nothing new... but still this holds).

In the last few days and weeks thinktecture's friend Edward Bakker and myself have been working on improving our DSL for modeling service contracts. This is surely just a start - it only is responsible for dealing with the WSDL-isms of service description and still relies on XSD for the data and message contracts. And no, we do not (yet?) deal with policies.
But it is a start and Edward is most certainly the expert in DSL Tools outside of Redmond's walls.

I could just copy and paste what we were doing and thinking, but Edward did a good job in documenting the evolution of this small and neat DSL.
To be clear: this is not meant to be a product, this will not make it as is into any tool. It is just for us learning the power and flexibilty of DSLs and to get used to the (currently still quite cumbersome) DSL Tools from Microsoft.

DSLs will make their way - maybe not our TSDL (thinktecture service description language) - but at least we start a fire.

Comments

[Ralph]

Hi Christian. You should look into IPolicyExporter and IPolicyImporter. I'll post a sample tonight demonstrating how they work. Cheers, Ralph

[auto insurance]

hello