Tools to create, tools to consume, tools to check
As a number of my colleagues have already pointed out the December download of the DSL Tools are now available. Three walkthroughs giving more detail on how to use these bits should also be available soon - hopefully before Christmas, if not early in the New Year.
Not only do these bits allow you to create a graphical designer in Visual Studio for your own domain specific language, but also they create the environment for executing text artefact templates against domain data created using your new designer. For example, such templates can be used to generate code from the data or reports about it.
Artefact templates are an example of tools that consume the data. A designer is an example of a tool that creates it. DSL tools are all about enabling organizations to automate more and more aspects of their software development process, using domain specific abstractions. But however good the designers or editors are for creating the domain data, if they don't provide easy access to that data by other tools then this won't be possible.
There is work to do in this area. In the shorter term this includes persisting the data in a domain specific XML format, rather than the generic format used in the December bits, and providing the hooks for other tools to load persisted data and access it through a domain specific API (noting that we already generate the appropriate hooks to access the domain data through a domain specific API from within artefact templates). In the longer term, it's the authoring experience for building the consumption tools themselves that could be tackled. Examples of such tools would be tools for performing transformations between data in different domains, tools to synchronize and reconcile data across mappings, tools to simulate or animate behaviors specified by a DSL, and so on.
A third kind of tool is a tool to check the well-formedness of data. This is somewhere between a tool that consumes data and a tool the creates data - checking can be an intrinsic part of both the creation and consumption process. For example, data that inputs to artefact generators may need to pass a set of validation checks (in addition to ones which are intrinsic to the domain data) to guarantee successful artefact generation.
To conclude, the DSL Tools are not just about making it easy to build visual designers, tools for creating data, but also about making it easy to build tools that need to consume it and check it, in the context of automating aspects of the software development process. At the very least, we need to make sure that the data is easily accessed, both through APIs and the way the data is peristed in XML files. Even better if we can provide direct support for authoring such tools, such as the text artefact template technology.