DSL Tools Deployment - Domain-specific WiX or a DSL?

None other than Rob Mensching himself, the godfather of WiX, is kind enough to mention our new deployment feature on his blog. (And rest assured, we've already fixed our slightly embarrassing file extension typo bug :-) ).

As Rob says,

"The DSL Setup Project is a specialized setup package builder."

i.e. it is a domain-specific setup builder (in the domain of creating DSL designers). Of course, as soon as we sniff this pattern in our code we do our darndest to dogfood. Consequently, the language used to specify the setup isn't just a plain ol' schematized xml file, rather it is a DSL tools language itself, albeit one without a graphical editor.  In actual fact we generate the XSD directly from the domain model definition.

You might be thinking that if the DSL tools make it so gosh-darned easy to create a graphical designer for any-old DSL, why didn't we do it in this case? Well it's a case of trying hard not to treat everything as a nail, given we have a hammer.

We get huge value out of going beyond schematized xml with this file; we can use our validation framework to do really rich validations of the file, far beyond what's possible with XSD and we can process the file in our text templates using a nice friendly .Net object model rather than a using a nasty DOM or other non-domain-specific API. So it's a no-brainer to use a DSL model.

However, it's not so obvious that a graphical language would be a great experience for processing this model. As models go, it's long on detail and lists and short on relationships (in fact it has no relationships). This screams "Forms-based UI" at me; some classes of model data are simply best expressed using traditional GUI elements rather than diagrams.

As the model is small, and the XML editor in Visual Studio 2005 is so good, we think the xml experience for editing this particular model stands up right now (unlike our designer definition file which we've heard loud and clear from you needs an editor).

Maybe we'll create a WinForms-based editor for this model (we haven't built bits to generate those automatically for a DSL just yet) or provide an InfoPath form for editing it. 

What do folks think about the experience of launching InfoPath from Visual Studio? Does everyone even have Office 2003 on their Dev boxes?