The VXML, CCXML Great Divide

Often I ask myself why CCXML and VXML exist. Couldn't one magnificent XML language support both the advance call control as well as the dialog control language? As anyone knows the dependence of different languages on disparate systems is an open invitation for disaster. Consider the following conditions,

1. CCXML invokes a VXML session, next this session exits and a transfer occurs in CCXML to another recipient. When this transfer is finished, another request for a VXML session is started. But before this session can start, a VXML session is required. What happens if all VXML resources are exhausted? Thus are now faced with the dilemma of dealing with an existing call that has to terminate abruptly. It is this dependency on resources that are not controlled as a single entity that leads to disaster.

2. CCXML invokes a VXML session. This VXML session exits for some call control reason (a transfer etc). Next a *NEW* VXML session is started to continue on with the dialog the original VXML session was handling. But hold on a minute, we now have committed an application cardinal sin. Sessions are becoming woven into a tapestry of confusion (yes I did make up this line). The power of VXML application and session management has been disregarded. Could something this simple have been overlooked? Should the VXML session remain active somehow? Since CCXML create the dialog, shouldn't it be responsible for terminating it. What happened to separation of powers? So how can one solve this? Well a new VXML tag that pauses it specifically so control can be returned to parent owner session. So now we are introducing tags specifically to deal with the separate layers.

So back to my original point, if we need to introduce VXML tags to support two disparate systems, why not just put all the tags there in the first place?