Thanks for the post, and welcome to ORM.
Is NORMA separated enough
NORMA is heavily tied to the DSL tools components in Microsoft.VisualStudio.Sdk.Modeling assembly. Using this assembly outside of a machine with a VS install is a licensing issue, not a technical issue. VS was chosen because of the available utilities, from the windowing and command framework, to the ability to directly plug an .orm model into any other VS project. My view is that forcing a user with an existing project to abandon their framework and make the model the predominant overarching context for everything else is not realistic, but that there are many places where models can be integrated. Any time you need any data structure--from a DB to an XML file to a block of registry data--you should be able to describe that data with a model and generate the appropriate code.
The transacted object model framework provided by DSL was chosen specifically because it natively supports delete closures, meaning that delete propagation is calculated, marked, and notified before elements are removed from the model, not after. This allows us to determine what parts of a model need to be revalidated when an item is deleted. Without this supported, scalability and live validation would be constantly at odds with each other.
The presentation layer is a view on an underlying DSL domain model. VS2010 has a WPF view, but I have not had a chance to delve into it yet (see response on next bullet). There was a project a while back that opened a .orm file in a web page in a WPF view (sorry, I don't remember the location). Note that you can load any .orm file outside of Visual Studio and read/manipulate the object model the same way you would do internally. The code is:
ModelLoader modelLoaderInstance = new ModelLoader(new ExtensionLoader(ExtensionModelData.LoadFromRegistry(@"Software\Microsoft\VisualStudio\8.0\ORM Solutions\Natural ORM Architect\Extensions", null, null)));
Store store = modelLoaderInstance.Load(ORMFILE);
You can then use the ElementDirectory and DomainDataDirectory collections off the Store to navigate the model. For example, store.DefaultPartition.ElementDirectory.FindElements<Diagram>(true)) will give you a collection of all diagrams in the model. You will be able to render this directly in WPF.
Is NORMA being extended to work with VS 2010
I've done initial investigation, and have a week blocked out this month for the port. I don't know if I'll make the release date, but I'll try. The initial issue is that the VS package registration is different, which will require setup and registration changes. The initial port will likely use the old DSL surface instead of the new WPF one, but getting things running at all on the new system is the top priority.
The actual drawing surface is a view on an underlying transacted model that has elements such as ORMDiagram, FactTypeShape, ObjectTypeShape, SubtypeLink, etc. that are in turn special implementations of Diagram, NodeShape, BinaryLinkShape, etc. from the Microsoft.VisualStudio.Modeling.Sdk.Diagrams assembly. The design surface code is relatively small, with the largest chunk of custom code in the FactTypeShape.cs file (~6k total lines). Much of the code here is for editor and toolbox interactions, dynamic color extensions, etc.
Eventually, we would like to get a full NORMA metamodel in .orm, and we're working through the formal derivation rule and dynamic rule extensions and corresponding generators we will need to model this complex of a system. This will give us the opportunity to generate to different systems, and make it easier to host the tool in other environments. However, even with the core model in place, the majority of the hand-written NORMA code is not in the model rules, it is in the editors surrounding the core, ranging from the Model Browser (a standalone system that has no knowledge of ORM or DSL) to the sample population windows, fact editor, verbalization window, and all of the other windows you see. Duplicating this in a disconnected web-based system and getting anything close to a responsive UI would obviously be a non-trivial amount of work. This code tends to be much less pattern-based than the shape and rule code, most of which follows a handful of patterns, so would be harder to replace.
If you'd like other details on how to get a dev build of NORMA going please contact me off line. Be careful: you need to run either a setup install of a NORMA or a locally built development version. They don't interact well.