The DICOM standard is often a victim of special interests. Unlike, for example, the IEEE, the DICOM standardisation process does not require multiple interoperable implementations; in fact, it does not require any implementations before something becomes standardised. Prior experience in implementation is desirable, but the process will not wait for implementations and testing.
As a result, Part 19 is a mess of inconsistencies. The XML data model – itself a questionable addition at this time – is specified using RELAX NG Compact, while the SOAP interface is expressed with WSDL and XSD. The WSDL itself is obviously tool-generated, and contains a reference to a Microsoft schema. Worst of all, however – the host and application interfaces use different namespaces.
A significant part of the point of using Web Services is to make use of the existing tool support. For that reason, the specification should be written to make the best use of that tool support. I have no particular issues with RELAX NG Compact as a validation technology, but it does not have the straightforward built-in support that XSD enjoys. Both .NET and Java (JAXB) can generate serialization code automatically from XSD; there seems no reason for RELAX NG to enter the picture.
Using different namespaces for host and application interfaces would be fine if there was no overlap between the two. Unfortunately, that is not the case here. Figure 8-1 in the Standard makes this clear: both host and application share the DataExchange, State, Rectangle and UID types, and all of their dependencies. However, any code generated from these two interfaces will generate two sets of all of these types, and duplication of code is the inevitable end result. It is clear that a well-thought-out interface would have none of these drawbacks.
It is possible to create a clean, simple interface in one WSDL file with one schema that is used by both host and application. Without an attempt at implementation, these issues were not found during standardization – and now may never be fixed. I hope that a future interface may address these problems.
Next time: data transfer.
David McCabe's Blog 