From my perspective, the most important set of specifications that developers should pay attention to are the WS-I Profiles.
A WS-I profile takes an existing set of standards and/or specifications and goes through them with a fine-toothed comb, finding all possible ambiguities (any place where the specification says MAY or SHOULD rather than MUST) and all places where some important behaviour isn't completely specified, and then the profile constrains the specs and says "don't use these features -- always do it this way". This type of profiling is particularly important when dealing with non-standardized specifications, such as SOAP 1.1 and WSDL 1.1, because these specs have a lot of ambiguities. But profiling is also necessary with more formal standards, such as WS-Security, which offer a broad spectrum of options and choices, or with UDDI, which provides a basic registry protocol, but doesn't go so far as to provide a specific model for registering services.
WS-I's first deliverable was the Basic Profile (BP). The WS-I BP defines guidelines for developing web services using SOAP 1.1, WSDL 1.1, and UDDI 2.0. There are many ambiguities, contradictions, and errors in the SOAP 1.1 and WSDL 1.1 specifications, so it's critical that developers follow this profile if they want to build interoperable web services.
WS-I has also defined an Attachments Profile, which defines guidelines for passing attachments using SOAP with Attachments (SwA). Unfortunatley, because Microsoft refuses to support SwA, the Attachments Profile doesn't really enable interoperability. I can understand Microsoft position on SwA, though -- SwA is a remarkably insecure mechanism for passing attachments. In the future (probably 2006), most SOAP platforms will adopt MTOM as the standard mechanism to pass attachments, and Microsoft is implementing support for MTOM in Indigo. (I'll be posting more on attachment mechanisms in a future blog entry.)
As the name implies, the WS-I BP is a basic profile -- meaning that it supports only basic communications -- it does not define how to use security, reliability, or any other advanced features. But it is the bible for how to build basic web services. The biggest constraint defined by this profile is that it disallows use of the SOAP encoding system. The profile describes in detail how to build web services that use either Document/Literal or RPC/Literal style message formats. I'll go one step further and recommend that developers build only Document/Literal services. Developers should avoid using RPC/Literal because many SOAP implementations (including the two most popular implementations: .NET and Apache Axis) don't support RPC/Literal. (Axis 1.2 can support RPC/Literal, but it doesn't work very well. Microsoft is adding support for RPC/Literal in Indigo. But even so, I still recommend Document/Literal over RPC/Literal. I'll be posting more on message styles in a future blog entry.)
WS-I is currently working on the Basic Security Profile (BSP). The group has published a very interesting document that discusses the various Security Challenges, Threats and Countermeasures associated with using web services. The BSP profile (which is still in draft form) describes how to use transport-level (SSL/TLS) and message-level (WS-Security) security mechanisms to secure SOAP messages.