There's been some debate about whether or not the WS-I should profile schema or not. I lean a little bit towards that it's a good thing, but I think the rub will be whether Web services can use a reasonable subset. TimE posted some intial thoughts and then comments on profiling schema and I'll respond to some of his points.
I think that Tim, and others, miss a big point. The effort at WS-I is largely a user effort. They simply can't get interoperability across the implementations of Schema. As a result, they have to figure out which toolkits support which subset and then do the intersection of the subsets. Yuck!
This makes users unhappy. Now they can react in a couple of ways. Tim suggests "If your development tool of choice can't handle an aspect of XSD, don't try to restrict what I do, pick a different tool.".
So this means that if .Net doesn't support something then all of .Net should be thrown out? We all know that a company is *not* going to throw out all of .Net Web services because of some "technical" schema problems.
Seems to me that if I was a dominant vendor and I knew I was forcing every user and vendor to figure out what I was doing so that they could then try to get compatibility, I'd be loving it. They do a lot of work that I don't have to do. That's one way to win at standards, is to force others to do work you don't have to.
As it happens, the customers don't want to do this work. And they were promised that WS-I would be a forum for customers to help foster interoperability. They were told they should join WS-I, give their feedback, and WS-I would deliver interoperability. In fact, they were told that if they adopted WS-I "Profiles", they would get guaranteed interoperability.
So they've reacted in the *ONLY* way that WS-I lets them, they want a profile that guarantees intoperability!
For their needs to be met in this way, it requires 2 big success factors:
1. The vendors listen to the customer. What happens when the vendor doesn't want to listen to the customer? I think this is a similar reason to why the W3C Web Services Architecture WG failed: vendor did not want to listen to the customers say things like "give us the roadmap for specs" or "standardize this part now please" or "give us the architecture for how these specs fit together"
2. The members can agree on a reasonable subset of Schema for Web services. I'm dubious that the customers will agree, and I pointed this out in the f2f meetings that I attended. I also think we will see lots of vendor pushback on this, but it might be related to success factor #1. For example, Tim points out "for instance, XHTML 1.1 uses groups and redefine. If those are profiled away, you wouldn't be able to build a compliant service that sent or received XHTML in messages)." An obvious counter-argument is that WS-I doesn't care about XHTML!
If I was in the customers shoes, I wouldn't be too happy if I joined WS-I to try to foster Web services interoperability and the first big customer push ended up being defeated. This is the first time they've tried to flex their muscles. And I can't think of a bigger pain point that they have with Web services that they are using right now.
What are they supposed to do if they can't influence Web services in this way? I think the success or failure of this effort will largely shape whether WS-I is a vendor organization or a vendor/user organization.