For example, a system where the developer does not need to write source code any more, instead they can using XML or some defined text to construct the application-level logic.
While you can surely write programs in XML (after all, XML's just a way of serializing a labelled tree structure with embedded strings) it's not going to help you out with programming. The hard part of programming is not writing it down, it's comprehending what exact assembly of concepts need to be told to the computer to make it do what you want to happen.
I have written IDEs. I have written visual programming languages. (It's a heck of a lot of work.) Any time you want something complex, you're going to end up with a complicated description. I happen to think that the easiest way to manage the complexity is with plain text in a structured language spread across multiple files, and there are excellent tools to help with such things.
Yes, you can of course, but at the end of the day that would become the source code. One can just replicate the tree structure of the source code (expressions that call subexpressions and so on) and write it as XML.
And if you take the care of adjusting the syntax to remove unneeded cruft, you may end with Scheme :-)
The problem with these type of solutions for the general case is that "end-users" tend to think and write in terms of "what I want", which can be extremely wooly, whereas computers work in terms of "what you said".
For example, if a user says "delete all the unimportant stuff", the computer can't handle concepts like "unimportant" and "stuff" unless the user specifically describes that to them (e.g. "Every file and folder that I've marked as unimportant".
You end up having to define stuff more and more specifically, and at some point you find you've got variables and functions, and basically a prototype scripting language, which no non-developer would want to touch because it's too complicated.
However, in any SPECIFIC case, your scripting language can take advantage of the limited scope of the user's interest to limit the language to the set of rules that they're actually interested in writing. Note that's the kind of task that entire companies and university theses are built around.
For example, if your client wants to be able to compare balance sheets according to user-defined rules, you could provide them with a client that handles all the things at computer level, but allow them to define the fields that they want to compare, and use a specific syntax for setting up rules on how to compare them. You may recognise this as the basic use-case of Microsoft Excel.
To give another example, Spiderweb Software has several "Blades of Exile/Avernum" Editors to allow users to create their own levels & scenarios for games. All the AI and UI is handled for the user. What the user sets up are the event flags that occur when you move to a particular space, what monsters will be in a particular room, etc. What was originally handled by the game creator carefully setting up position variables and trigger events in the source code, is now generalised and with a clean UI over the top of it, which generates the kind of scripts that you're talking about, which are then read by the game engine.
First of all, what you are going to define will be simply a new programming language. You will have to define the language, its semantics, and implement a compiler or interpreters for the language. So, you are not going to take away the task of programming from developers.
Maybe you can make a very simple language if you have a very restricted context where programmers only have to specify certain options in an XML file and you have a framework that takes care of the rest. This would look more like customization of an existing application. However, as soon as you have some non-trivial application your language will grow very fast into a more traditional programming language (with data structures, control structures, variables, libraries, and so on).
If your issue is only about the syntax: XML is easier to parse but (IMHO) less readable.
Making XML into a programming language reminds me of the many failed attempts in the aviation world to take a small automobile, add wings, tail, and propeller in order to make a flying car.
You wind up with an unsafe airplane and a crappy car.
XML is a great way to transfer data between disparate systems. Trying to make it into a programming language is really going to be an exercise in frustration and futility.
Not only is it theoretically possible, there is already a language defined and implemented -- it's called XML Plus Plus. It hasn't been developed in a while, though, but seeing as it is apparently open source, you should be able to continue developing it if you want to.
However, as has already been said and as you can see from the code samples you can find of XML Plus Plus, the language is not particularly pleasant to program in, and requires all the same mental effort (plus a lot of extra typing).
I worked with Tango/WiTango/TerraScript that is basically an XML-encoded language (with a really nice drag/drop tree-based IDE). It compiles to J2EE or can be executed with its own run-time as well. It has been XML-based for about 12 years now.