I've worked on a few web games in the past and, to be honest, none of them have ever needed anything this complex and unwieldy.
XSLT can be bulky to manage, and essentially adds an extra programming language that developers would have to work in (at least if I understand your description correctly). My experience has been that relatively few people know it, and even fewer can make it do what they want.
I think you are looking at a highly complicated solution. It is a major effort to simply design and build out the Schema's that you will be using. If your on a project that involves more than 5-6 people total you likely need to have an organized schema design effort. I think this is a point you are aware of.
I question and possibly take issue of the selection of PHP on the front end. I also think you are deciding on XML in a large sense mistakenly.
Here is what I do:
- Build a service layer using Grails.org
- Keep every resource that can be RESTFUL in rest
- Use the X-fire plugin in Grails to build out any SOAP services that need to be built
- Take advantage of GORM and RAD functionality of Grails to reduce development time.
- Construct clients in X or Y language or platform to consume these services.
I definetly would want the speed of pure Java doing all of my XML translation/processing. If you have large documents then it will take considerable time processing these.
You understand the forces of your environment better than anyone, but I would caution you to do the simplest thing that works first and not over-architect.
I'm not sure what "flexible framework" to suggest to you either. It all kinda depends on what you're comfortable with and your personal taste.
One thing I do know is that, how appealing it may look at first, is to stay away from XSLT. Doing Hello World type stuff and simple examples with XSLT is pretty straight forward. However, more complex projects become completely unmanageable (not to mention unreadable) with XSLT. My experience is that it puts a massive strain on the project.
What you describe could likely be implemented using tox. It uses a hybrid MVC-ARS architecture. The obstacle that I see is the cost point tox presents because of its dependency on Oracle. Of course, since it is open source, you could convert it to Postgresql.