-less vs. round-trippers"> So UML support will be provided through Microsoft or through partnering? We will do some of them. And it depends on if youre talking about UML 2.0 or UML 1.4.x. For UML 2.0 we will certainly rely on partners on our platform, building on our infrastructure to deliver a full UML 2.0 implementation. And we will deliver some of them ourselves. So we will certainly continue to deliver the Visio modeling tools that we have, which are UML 1.4 compliant. So well continue to deliver those tools.And then the strategy is to take the key domains out of the UML model that we think are really critical. And there are some of them. Like "use cases" is very interesting. Its a very interesting domain in and of itself, so we think that over time we will build use-case designers directly into the tooling. And then there are some that will look like what UML produces but are in fact domain-specific.So let me give you an examplethe sequence designer. In UML they have a generic sequence designer for designing sequences of integrations between anything. We have the notion of a WSDL contract designer, and it has very specific semantics because WSDL has very specific semantics. It looks a lot like a sequence designer. We will not ship that in the first version, but when we do ship it people will look at that and say, "Hey, thats a sequence designer." Well, it mostly is a sequence designer, but it has very specific semantics towards a problem domain. Now, why should anybody care about that? Here is the one gem I have learned in the five years of dealing in this space, from some incredibly smart people weve got that have been working in this problem space for 20 years. And that is that the closer the underlying representation is to the model, the more likely it is that you can have a trip-less experience. And the notion of "round trip," which UML talks about, I think is just wrong. I dont want round trip, I want trip-less. I want the relationship of a view to a database table. It can never be out of synch because its just a view of the same data. Thats what you need to get to from a tooling perspective to make this stuff work. And thats why, quite frankly, people dont use UML. They may use it to document, they use it to do some initial design, and then it goes by the wayside. And I think, with all respect to Grady [Booch, co-creator of UML], I think were a long way away from executable UML. And the challenge is because there is such a transformation in the semantics, between the underlying implementation into a UML model, that isnt exactly precise to that domain. So the closer you can get your domains [to] those underlying implementations, theyre just views of the data and that works. And when that works people will use it. I came from the world of writing C++ compilers. Im not a modeling guy. And when I think about the world of the promises of CASE, Im exceptionally skeptical. I was at Microsoft in the late 80s when CASE tools were going to be the thing. And they never materialized because of this disconnect between implementation and the metamodel, and the cost of keeping those in synch. So if you can solve that problem then I think you have a world-class designer strategy, which is where were going, and which is what we think the domain-specific language approachagain, not invented by usactually enables you to do. Next page: Defining domain-specific languages for Web services.