David Booth
W3C Fellow / Hewlett-Packard
This document describes several options for addressing semantics in WSDL 1.2, which currently says nothing about semantics.
This document has no official status. It represents the thoughts of the author. Comments welcome.
The purpose of WSDL is to describe a Web Service in a machine-processable format. At present, WSDL is focused on the syntactic level of the Service inputs and outputs -- describing the message and datatypes to be exchanged -- while saying nothing about semantics of the Service, or what those messages mean.
This is adequate for some uses, in which the Service and its Clients operate in a relatively fixed relationship, and they independently agree on the intended semantics. But if we wish to use a WSDL document in the context of automating higher level processes, then we need a way to unambiguously identify or express the semantics of a Service, so that those automated processes can make sensible decisions about the Web Services that they use.
Before reading further, please see the section on The Need for Explicit Semantics currently in the WSDL 1.2 Primer draft for a gentle introduction to the need for semantics in WSDL.
I would characterize four rough levels of dealing with semantics:
Level 0: Implicit semantics. Totally ignore semantics in WSDL. Leave semantics entirely up to out-of-band mechanisms. In other words, given an arbitrary WSDL document, there isn't a deterministic process for a human or machine to either identify or discover the document's semantics.
Level 1: Identify semantics, without defining them. The WSDL document unambiguously identifies the name of its semantics (either directly or indirectly), though it may not be possible to discover what those semantics are. For example, the URI specified by the top level targetNamespace might unambiguously identify the semantics, even if no document is ever intended to be placed at the end of that URI. It is useful to unambiguously identify semantics even if the semantics are not defined, because if two WSDL documents w1 and w2 refer to the same unambiguous name to identify their semantics, then you at least know that they are supposed to have the same semantics. Furthermore, if you know s1 about the semantics of w1, and you know s2 about the semantics of w2, then you can infer that both w1 and w2 must have semantics s1+s2. (On the other hand, if two WSDL documents use different targetNamespace URIs, they do not necessarily have different semantics.)
Level 2: Define semantics in a human readable format. The WSDL defines its semantics (either directly or by reference) in a human format. For example, the top level targetNamespace might hold the URL of an HTML document that defines the semantics. Not only do we have an unambiguous name for the semantics, but we also have a way to find them.
Level 3: Define semantics in a machine-processable format. For example, the top level targetNamespace might hold the URL of an RDF document that defines the semantics in conjunction with one or more ontologies. Obviously, this would provide the greatest precision and permit the greatest automation.
At present, WSDL 1.2 is silent about how the semantics of a Web Service should be identified or discovered. This means that given an arbitrary WSDL document, there is no well-defined way to either identify or determine its semantics.
Some people assume that the use of a namespace already identifies the semantics. Although this is very often the author's intent -- indeed, many authors follow the practice of placing a document at the end of the namespace URI to define semantics of that namespace -- there is nothing currently in the XML namespace specification or the WSDL 1.2 specification that specifically recommends this interpretation. [Another possible interpretation is that the namespace is only intended to unambiguously identify the syntax, which might have various semantics applied in different contexts.] This means that without an exhaustive list of all namespaces that do follow this convention (which is clearly infeasible), it is impossible to know whether a given namespace was even intended to identify the semantics.
I see 4 broad options, with some additional variations:
Option 0: Do nothing.
Option 1: Identify semantics. Add something to the spec along the lines of:
"The targetNamespace URI represents an unambiguous name for the intended semantics of the WSDL document. However, WSDL 1.2 does not require any document to be at the end of that URI, nor does WSDL 1.2 specify what kinds of document might be at the end of that URI."
Option 2a: Suggest but don't require defining semantics. Add something to the spec along the lines of:
"The targetNamespace URI represents an unambiguous name for the intended semantics of the WSDL document. The targetNamespace URI SHOULD point to a human or machine processable document that directly or indirectly defines the semantics of the WSDL document."
Option 2b: Require semantics. Add something to the spec along the lines of:
"The targetNamespace URI represents an unambiguous name for the intended semantics of the WSDL document. The targetNamespace URI MUST point to a human or machine processable document that directly or indirectly defines the semantics of the WSDL document."
Option 3a: Suggest machine processable semantics. Add something to the spec along the lines of:
"The targetNamespace URI represents an unambiguous name for the intended semantics of the WSDL document. The targetNamespace URI SHOULD point to a machine processable document that directly or indirectly defines the semantics of the WSDL document."
Option 3b: Mandate machine processable semantics. Add something to the spec along the lines of:
"The targetNamespace URI represents an unambiguous name for the intended semantics of the WSDL document. The targetNamespace URI MUST point to a machine processable document that directly or indirectly defines the semantics of the WSDL document."
I suggest option 2a. It clarifies the use of the targetNamespace URI to identify semantics, and it encourages people to explicitly define semantics, but it does not force anyone to define semantics. It would be nice if we could be a bit more forceful, and require the URI to point to the semantics -- ideally in a machine-processable format -- but I don't think that's realistic at this point.
$Revision: 1.10 $ of $Date: 2002/11/15 18:24:37 $ by $Author: dbooth $