The official schema namespace for WSDL 1.1 is http://schemas.xmlsoap.org/wsdl/. But, and here is the fun part, the schema for that namespace given in the official W3C WSDL 1.1 note and the schema for that namespace given at the actual XML namespace URL are different. But wait, it gets better. Not only are the two schemas different, they aren't even compatible with each other! I'll give the gory details below but the bottom line is that there exist two incompatible versions of the WSDL 1.1 schema, one in the W3C note and one at the actual XML namespace URL which use the same XML namespace and the same element names. Just to add to the fun the WS-I has officially approved the schema at the actual namespace URL in contradiction to the schema in the W3C WSDL 1.1 note. So now implementers get to pick which industry body they favor since they have competing, incompatible, definitions for the WSDL 1.1 schema. I suppose errors like this make it more understandable why versioning in Web Services is such a disaster.
Taking a quick look at the W3C official WSDL 1.1 schema and the schema provided by the WSDL XML namespace URL and one can easily see that they are defined using completely different XML Schemas. But XML Schema is flexible enough that one can write schemas that are totally different but validate the same XML structures. Unfortunately, that isn't the case here.
The root element of a WSDL is the definitions element. In the W3C WSDL 1.1 note the definitions element is defined to be of type wsdl:definitionsType. If you look at the definition of definitionsType you will see that it is a sequence and at the bottom of the sequence is an <any> element. This means that anyone wanting to put in extensions to WSDL must put those extensions at the bottom of the definitions element.
Now look at the schema at the actual WSDL 1.1 XML namespace URL. In that schema the definitions element is defined to be of type wsdl:tDefinitions. tDefinitions is defined as an extension of wsdl:tExtensibleDocumented. tExtensibleDocumented is defined as a sequence whose only contents is <any>. The way extensions work in XML Schema is that an extension is glued on to the end of the thing being extended. So what that means is that the definition for tDefinitions is effectively an <any> followed by the contents of the WSDL file.
In other words if someone wants to put in a WSDL extension then if they use the schema in the W3C WSDL 1.1 note they need to put the extension at the end of the WSDL file. If they use the schema in the actual namespace then they have to put the extension at the beginning of the WSDL file. In other words, the two schemas, both of which have identical XML namespace and element names, are incompatible with each other!
The WS-I did address this issue. What they said in Basic Profile 1.1, in requirement R2028 is that the 'right' schema is the one available at http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd which is different than the schema in the W3C WSDL 1.1 note. Which is all very nice and good but if you look at the schema at the WS-I recommended URL you will see that they didn't change the namespace! So now we have two different industry organizations (the WS-I and the W3C) both officially standardizing two different, incompatible schemas, under the same XML namespace with the same element names. Which, btw, should give pause to anyone who thinks it's a good idea to have multiple standards organizations all working in the same space. Such things tend to lead to messes just like this one.
BTW, for anyone who is wondering, no, there is absolutely no good reason why the extension point should have been moved from the end of the file to the beginning. My best guess is that IBM and MS have adopted the schema definition style one sees in the WS-I schema and this style automatically ends up putting the extension point at the start of the file. But it would be very easy to alter the new schema so it put the extension point at the end of the file and so remain compatible with the schema in the W3C WSDL 1.1 note. So the whole incompatibility is, I strongly suspect, just a screw up. Somebody, somewhere, didn't do their homework.
Now any standards (such as the one I'm working on, BPEL), that depend on WSDL are in a pickle. BPEL defines extensions to WSDL, so in examples and such where exactly should it show its extensions? If it shows them at the end of the WSDL file then it is compliant with the W3C but not WS-I. If it shows them at the beginning then it is compliant with the WS-I but not the W3C.
If even the 'experts' can't get Web Services versioning right, what hope does anyone else have?
At least to my knowledge, derferencing namespace URIs as though they were URLs and expecting to get schemas is not a requirement of the XML Schema specification or the WSDL specification. (It is specified as optional therein.) The presence of the W3C version of the WSDL 1.1 schema at the URL that is equal (as a string) to the namespace URI is simply a coincidence. You might compare some of the discussion here with your comments: http://lists.xml.org/archives/xml-dev/200410/msg00618.html
Dereferencing isn't the issue. The issue is that there now exist two incompatible schemas that are running around under identical namespace names. So someone who implements based on the schema in the WSDL 1.1 note will end up with the same result as someone implementing by downloading the schema from the URI or following the WS-I BP 1.1 spec.
WSDL 1.1 is a Note, not a Recommendation. Notes are not meant to be treated as bullet-proof specifications. It is not surprising that the schema in this Note is buggy, or that it needed to be refined via WS-I. The interesting issue is this: Why hasn’t the industry created a usable and more bullet-proof WSDL 2.0? The WSDL 1.1 Note is more than 4 years old now.
The problem is that nobody, anywhere was willing to accept WSDL 1.1 as a note, it has been universally treated as if it were a recommendation. This is a very common problem in standards where consumers of standards are woefully ignorant of what the different labels mean. As for why it has taken so long for WSDL 2.0, well, you know, boiling the ocean does take quite a bit of time.