There was a real danger that the major players in the new market for Web Services would thus be able to offer "hand on heart" support for standard XML, while manipulating schema to create proprietary systems. Fortunately the user organisations have for once been quicker off the mark and as a result standards have been developed for schemas as well as the XML language itself.
In the early days the language for marking up text was SGML and with that a schema language called a DTD. This can be still be applied to normal documents in XML but it did not cover features needed for formatting data such as data types, etc., so that now XML schema are written in more specific languages, themselves rooted in XML. There is a standard for writing schema specified by W3C, but in practice there are two or three in common use today, each supported by one or other of the leading software suppliers. At one point this promised to develop into the usual fragmentation problem, but it hasn't. This is because various user sponsored organisations have developed higher level application frameworks which are used by members, rather than getting involved with lower level schema coding. In a way these new schemas are akin to a high-level programming language and are often referred to as "XML languages".
The users had a big influence on the higher level schema/languages, but for once they were also able to put pressure on the big suppliers to agree on lower level (infrastructure) standards, simply because e-commerce involves inter-company trading and since there is no chance of all parties using the same technology, then even Microsoft, IBM and Sun, not to mention BEA, have had to conform and to work to common standards. Indeed it is these suppliers who are running the consortia that are specifying the inter-working standards, not before time.
The current situation then is an encouraging one. Most of the essential services needed to implement comprehensive Web-based applications are now adequately defined, good enough for significant applications to be developed which will work cross-platform. Equally important all the major software development tools have developed rapidly, given a set of APIs to work to. Of course there are still a wide choice of suppliers of core systems and there are at least two different technologies to choose from, Microsoft's .NET and J2EE supported by everyone else. In practice this is a good scenario, because competition leads to advances, while with only two systems involved there are plenty of practical tools to port code from one environment to another. In any case by working to the Web Services standards, applications written in either environment should work together.
There are two significant frameworks on which to build new e-commerce applications, BizTalk (developed by Microsoft) and ebXML (developed by OASIS). Both are intended to support a range of programming tools, object models, etc., although in practice BizTalk tends to be devoted to Microsoft technology. The objective of these frameworks, which are application neutral, is to provide protocols for message flows between applications and to provide the structure for building and making schemas available. One other development is a protocol for managing transactions, an attempt to provide services akin to those commonly employed on more conventional systems. This is known as Business Transaction Protocol (BTP), and is part of ebXML. Lets hope that BizTalk will support the same protocol.
Other standards are being developed to aid the migration of older EDI systems onto an XML basis. Universal Business Language (UBL) is a recent ebXML development intended to provide a language to generate a set of building blocks for exchanging business documents; VCML is another contender. The inter-working of new e-commerce applications with the established X12 and other EDI formats is just as important as two new systems working together.
While the above "framework" subsystems are critical if applications are to be built quickly and reliably, the core Web Services standards that underpin them and the whole host of business specific higher-level services will also need to be looked into.