Acropolis uses XAML to define business logic components

A lot of developers are mistaking XAML to be an exclusively WPF technology. The truth is, that as it’s name (Extensible Application Markup Language) suggests, it can be used to represent all kinds of application mechanisms, not just the UI.
David Hill has written a post with a brief explanation as to why Acropolis uses XAML instead of code to represent its business logic component. Check the “Why XAML?” section under this post.

Using a declarative approach like this, though, provides a number of benefits:

• Using XAML gives you a very concise way to express the structural aspects of your component – not just the external €˜class interface’, but how it is structured internally. For example, it allows you to cleanly define how any child components or services that your component uses are configured or interact with each other.
• It allows you to concentrate more on the code that defines the actual implementation of your component. In other words, we want to make it so that 99%+ of the code that you do write is the actual code that will solve your business problem and not plumbing or glue code.
• It is much easier for us (or you) to build visual designers or other tools (including test tools) for your component since its structure is more easily €˜machine-parsable’. It also allows for a looser coupling between the application model and the tools allowing each of them to evolve more quickly.

Since there is very little documentation I could find on the subject, I wonder how complicated is to create my own application markup and a designer for Visual Studio…
Anyone has any good pointers on this?