Simplicity implies a reasonable size (so the system can be understood) and well understood responsibilities (so that everybody knows what to do with what they understood). We can go further and realize that simplicity implies the minimizing the amount of knowledge about the system required to add a given feature.

Reasonable Size
The less code there is, the less design there is, the less there is to fuck up.

The goal is to implement the entire framework in 10,000 lines of code or less including class and method comments.

Maintaining a reasonable size means throwing a lot of functionality over the wall into plugin services. So even though the system is to have much of the XAML functionality, it will be provided by plugins - which adds flexibility and reduces complexity - and keeps portability and universality of the XML targeted at the frame work if the plugins required by the XML are specified in the XML and locatable by the framework.

Well Understood Responsibilities
Whether the responsibilities are well understood is, of course, a judgment call made by each user of the framework - but making sure that the areas of responsibility are few in number can only but help.

Minimal Knowledge Required
All application functionality will be provided using plugins (i.e. delegate any special needs of the application, which adds complexity, to the application or 3rd party tools).

All application data is managed and provided by the framework. It is the User's data, after all, an application just needs to work with it at the user's bequest - let the framework manage getting it to and from the application to wherever else the user wants to send it. This is a key feature gained from think about how Unix command line shells work and why they were/were not so successful.

Both of these also minimize the need for exposing and super-generalizing class methods in order to support inheritance unlike most other framework designs.

Declarative XML as the specification of application functionality has been proven to lower the entry barrier to using a set of features.

Basic MVC (Model - View - Controller) design transmogrified into a DSC (generic Data - Service - Controller) design

Services - All services are dynamically loaded plugins which read and write data. This data is persistent and may be defining or displayed in the GUI. It is not clear yet whether all services should keep volatile data in the system, or whether they can store volatile state locally.

Data - All data is persistent, highly-typed and referenced internally by URI. This creates data that more closely mimics the real world - and it is expected that any limitations with this system will be performance related. Features like partial loading of super large data structures and session management become extremely simple with this design.

Controller - Not really a controller in the MVC sense, this is almost completely free of intelligence, and mostly manages the adding and removal of its services and dispatching of service requests. Large numbers of event- and change-driven bindings which are created by the plugins during initialization and during activity might also be considered as part of the controller layer.

This is somewhat of a judgment call based on the initial applications envisioned by the author of the framework - but useful functionally in general seems to consist of:

The real world is persistent, one does not have to 'save their changes', nor would it be advantageous if we had to. The format of the persisted data is unspecified.

A corollary to this is that there must be a robust undo and version management/recall system so that mistakes, when made and persisted, can be reversed.

The approach taken is to make the general data structures persistent by default. Because most of the content represented by these general data structures needs to be persisted anyway - configurations, user profiles, application data, and so on - this is a win-win situation.

It would be great to have undo (do-overs) in the real world; this allows a user to explore possibilities in the application space much more freely with permission to make mistakes.

There also needs to be an ability to mark versions and to retrieve them and their undo history.

The approach taken is to make the general data structures persistent by default. Because most of the content represented by these general data structures needs to be persisted anyway - configurations, user profiles, application data, and so on - this is a win-win situation.

Extensive tracing and debugging support is required and should fit in to the core framework given its streamlined and constrained design.

Logging support will be provided by plugins external the the core framework.

The approach taken is to support Pluggable and Declarative Validation:

Highly-typed and validated properties - properties not only know their type and name, but minimum and maximum values and many other, pluggable constraints can be specified.

Highly-typed and validated data sets - relationships between properties and many other, pluggable constraints can be specified.

The system needs to be testable. This means virtual user testing - the ability to automatically test the applications written using Obsidian as if a million users were using it.

This does not mean unit testing - though unit testing is included because it is so easy to do with largely self-describing APIs like Obsidian has. Unit testing tests a functional unit, it does not test the veracity and appropriateness of the unit as to whether it is doing what its callers expect it to be doing. It is all fine and good to make the unit handle values it will never receive - assuming one has the extra time to do so - but this does not help achieve a bug-free application.