savas parastatidis

Mistakes in the example (SSDL core spec)

There are mistakes in the example of the SSDL core spec. This was due to a global replace that went bad 🙁 Here's how the <ssdl:protocols> element should have looked like in Example 1.

Thanks for Jacek for spotting this. I am collecting all the problems and posting them in an errata page. We can release updated version of the specs when we have more problems like this.

Now on to Jacek's points in his "SSDL mixed feelings" post. The introduction of the ssdl:messages and ssdl:protocols containers was intentional. A contract may have group of messages from different namespaces (note that an ssdl:messages element has a @targetNamespace attribute). This allows a contract to include groups of messages that have been defined in different namespaces. The same principle is true for ssdl:protocols where each ssdl:protocol may be defined in its own namespace, hence allowing different protocols to be part of the same contract.

Jacek also points out to the wrong message direction in the 'robust' MEPs. I'll fix that too. Thanks!

Now to Jacek's comments about the usage model... We believe in protocol-based integration. We care about the messaging behaviour of Web Services and not the semantics of abstractions like 'interfaces' and 'operations'. In a service-oriented environment, we only care about the messages that are exchanged and the protocols that are put in place. The semantics of the interactions are defined by the specifications of the contracts.

UPDATE: Links to errata pages fixed. Thanks Collin!

4 responses to “Mistakes in the example (SSDL core spec)”

  1. Jacek
    Regarding the containers: maybe I was confused because I didn’t read that contract/@targetNamespace is in fact no namespace, but an identifier for a contract. I wonder, why a document would need to have a URI identifying it inside, why it can’t just be put on that URI; and the attribute should definitely be renamed (“name” comes to mind, or “id”) if it’s not meant to be a namespace. Still it’s more common to have one namespace per document, therefore I’d rather keep contract/@targetNamespace, allow only (up to) a single messages container and drop targetNamespaces on the containers. (Then I’d drop the containers, too. 😎 ) The namespace could still be used as an ID of that document if multiple contracts in the same namespace were disallowed – no problem here. Basically the main problem with message/protocol/endpoint container-specific targetNamespace is the notion of what a document (contract) makes public. Normally a document’s namespace contains what the document publishes, and anything in a different namespace (for example stuff imported from other documents) is not visible to the users (importers) of the document. Import statements are then used to import stuff from a foreign namespace, but in SSDL when I import a contract, it can contain any number of namespaces and therefore there can be no simple check on an SSDL document that would discover usage of unknown (not imported) namespaces. I hope it’s less confused than I think. 😎
  2. Jacek
    Regarding the last paragraph, I believe that ultimately computers should be able to do a lot of discovery/choreography/invocation on their own, in which case they naturally will have to be aware of the semantics of the various interactions and sequencings of messages. In that regard WSDL provides me with a place where I can hook the semantics, for example I could attach a WSMO semantic description (and choreography or whatnot) to a WSDL interface and to all the schemata and then an automated agent would be able, ideally, even to mediate between syntactically different contracts that achieve the same thing. That’s what we’re working on at DERI. Maybe the approach of SSDL could be better in terms of just going step by step, but I fear that if we have to build a layer on top of SSDL (or pointing to SSDL) to which we could then hook the semantics, we’d end up with a result significantly more complex than WSDL. In other words, the basis (the service description language) should be powerful enough so that layers on top of it don’t have to deal with too much genericity.
  3. Savas Parastatidis
    The contract document has a @targetNamespace as well. This way a contract can be located in registries. The reason for @targetNamespace in messages is twofold. 1. It allows messages to be referenced by the the msgref element using QNames. 2. It allows messages to be defined elsewhere and then imported and used by the specific contract. It’s not uncommon for bussinesses to define commonly agreed document formats. Messages could be defined in a similar manner and then imported in a contract. Regarding semantics… SSDL is a specification on how to write contracts. The semantics of the contract itself is not part of SSDL. Granted, we haven’t allowed for extensibility elements to be introduced. We can do this. I recognise the need for semantics descriptions to be introduced inside XML documents. However, i completely disagree that the only way to associate semantics with a contract is through an abstraction similar to that of WSDL’s ‘operation’. Thanks for the feedback!
  4. Colin Gillespie
    Your link to the errata page doesn’t work.