Content or, in that case, services negotiation has always been desirable when doing deployment on a wide scale. Selection or negotiation relies on description of both the service and the consumer of this service, as well as the kind of selection, negotiation, matching process that may happen.
A service can be described in a number of ways, for the example we will use a Bookshop catalog Service with SOAP 1.2 service accessible via a HTTP GET interface. What do we have?
A consumer of a service have a set of requirements that needs to be matched against the service capabilities before actually interacting with the service. Service consumer may not be only an endpoint sending a message to the targeted service, it may be also a human selecting the right service based on a set of constraints, a machine selecting a service to be part of a global service interaction.
Amongst possible the constraints, we may have (not linked to the example above):
Matching constraints and capabilities may be done on features used by services, on global level policies, on application-level data. It is then a multi-level negotiation and may happen in one round or multiple rounds.
Negotiation can happen in different situation, at "runtime", like content negotiation in HTTP, or CC/PP, where all the information about the client capabilities is sent to a server, it may be useful in the request-response case, but with the drawback of requiring lots of information to be sent. Also not all capabilities are known from the sender side.
It can also happen at the web service creation, as some informations are available from descriptions (like WSDL description) the sending part may know in advance that the receiving part knows and understand MTOM and will send a request using this mechanism.
Automatic selection of services can also be done at runtime, automatically selection a service based on descriptions (select the one that have the more restrictive privacy definition), or can be done offline by presenting a set on constraints met and not met for a human to decide.
Using the decentralized nature of the Web, where multiple capabilities definitions may be linked together by an aggregator, an aggregator serving also a capability document, results from several levels of aggregations may be possible.
Also, the use of ontologies to align definitions (or to group a set of definition) might be useful while not mandatory. In a more general ways, the use of Semantic Web techniques may help a lot when a match between a set of capabilities and set of constraints is required. It may help but should not be mandatory, as no such matching algorithm should be precluded.
A single Constraint and Capabilities language is not enough to address the issue, a more comprehensive framework is required, but this framework should be extensible enough to accomodate most of the common use of this technology.