Kiss your favourite XML editor bye bye! (and welcome Domain Specific Languages designers!)

Note: this entry has moved.

With the advent of XML, each and every piece of software is configurable with it, from Virtual PC to IIS to log4net to Shadowfax and all the Application Blocks released from PAG ... you name it.

If you think about it, however, it's quite easy to realize that what those XML files are actually, is nothing more than a text-based representation of the concepts in the particular domain of the tool/app. So, log4net has the concepts of Appenders, Filters, Object Formatters, and so on, while Shadowfax (as most SOA frameworks) has the concepts of Pipeline, Handler, Service Action, and so on. Therefore, XML is just a means to express the particular layout/behavior you want these tools/frameworks to have at run-time. It's not about XML, stupid! It's about the Domain Specific Language (DSL) expressed in (serialized into) those tags.

A very important step forward to make these languages first-class citizens in the developer's minds and programming experience has been made by Microsoft with the release of the tools necessary to build your own DSL editors/designers. With these specialized editors, the need for a generic XML editor (when used to edit configuration) will dissapear. How many people do you think is using generic XML editors to create instance documents that are used as input for an application (other than just for testing purposes)? My bet: NONE (InfoPath doesn't count, as it's not an XML editor but a forms tool, which just happens to use XML as the underlying store). Generic XML editors, instead, have been primarily used to configure the myriad of tools/blocks/frameworks that you need to use to get your application up and running fast and with minimal effort (other than the one needed to configure it in the first place, an increasingly complex one indeed!). It's time to move forward.

That's why I think any effort put in creating generic/customizable XML editors is futile. I believe the future is a multitude of specialized designers for the different aspects of an application (their DSLs). I hope sooner than later we'll see an editor like this for tools like UIP, and we'll have nothing to envy the Eclipse guys...

1 Comment

  • Have you seen XML Spy or Authentic?



    XSL and CSS2 already make these first class citizens in terms of presentation in virtually every XML editor. Most XML editors can generate UI from the XSD.



    What audience do you think doesn't need a separate editor from Visual Studio?



    The aplication developer audience already knows their config settings, and the config settings provided in the file, and doesn't really need a configuration utility at all. After all, if you didn't comment <add key="fred" value="integrated security...">, and have forgotten what it means now, that's your own fault.



    The testing/QA environment does not have visual studio installed, so they have no way to get to the designer.



    In an intranet environment, the web people probably aren't programmers (sometimes they are, sometimes they aren't. in my experience, IT people in charge of web servers usually aren't strong programmers, and usually won't touch visual studio). So again, you have an audience that can't use visual studio there.



    In a remote-deployment or solution provider environment, you package up the compiled binaries ontol a CD, ship it and say hey run setup. Again no visual studio.



    So whose your market?

Comments have been disabled for this content.