You Can’t Rush the Standards
Guest Author: Jim Barnett
I’m Jim Barnett, a member of the Aspect Software Architecture Team. For quite some time, I have been actively involved with organizations such as the World Wide Web Consortium (W3C), working to develop new standards that I believe will be useful in contact centers, and businesses in general. I am also the editor-in-chief of State Chart XML (SCXML) – a language that is still early in the standardization process. Aspect Software is committed to open standards, and this is one of the reasons why I and my colleagues on the architecture team are so heavily involved in the standards-making bodies.
Because SCXML has received some media attention lately, I thought it might be a good time to report on where SCXML is in the development process, and when it will be ready for commercial use. SCXML is being developed as part of an attempt to revise and improve the VoiceXML language. One shortcoming of VoiceXML is that it mixes up user “interaction markup” with “call flow logic” making the two hard to untangle. For example, if one developer writes a nice routine to collect a credit card number in one application, it’s hard for another developer to re-use it in different application. There’s no clear division between the part that gets the credit card number and the part that decides where to go next in the original application. Here’s where SCXML comes in – it’s a new language that will factor out the flow control logic. SCXML, which can be used with VoiceXML or separately, will allow companies to control and integrate a variety of business processes and back-end systems.
I say “will” because the standards development process takes time, and SCXML is still in the development process. Each standard requires the formation of a working group, which is comprised of people who are experts in their respective fields. That group defines the functionality of the standard in great detail, and then publishes specifications that enable companies to implement it. Each working group dedicates countless hours to their standard. We spend a lot of time on SCXML – a phone call every week and three face-to-face meetings a year – but developing a standard involves getting a lot of different people to agree. To give you an idea of how difficult this can be, think of the slowest cross-functional team you’ve ever been part of and imagine that there is no executive you can appeal to for a final decision. That’s a standards committee.
We have been working on SCXML for about two and a half years and have already written three drafts of the specification. Each draft has contained significant changes, and I am certain that our next draft will also have a number of major revisions. Draft #4 will still be a “Working Draft,” meaning that the language will not yet be a standard, and we will be free to make major changes as we go along. I hope that draft #4 will be available within the next year, but cannot say with certainty due to the consensus-based process I’ve outlined above.
When our working group agrees that the language is clearly and correctly defined, we will enter the formal standardization process. This involves soliciting and responding to public comments on the language, as well as testing prototype implementations of it. At the end of this process SCXML will reach “Recommendation” status. At that point, the language will truly be stable and a standard. I can’t predict when we will reach that point, but I would expect it to be at least two years out. SCXML may change a lot before it reaches “Recommendation” status, and that makes it risky to develop products based on it – this is one of the problems with early drafts of standards.
What are your thoughts on standards and standards development?
Rate this Post:
(No Ratings Yet)
Loading ...