[New-ITS] [New ITS] - Industry Tool Support

[Grahame Grieve]

joseph.2.waller at bt.com wrote:
> Graham,
> 
> The two questions are actually kinda related.
> 
> Question 1 - When you create a WSDL you include a description of the
> interface as an xsd. This means that you generally include an xsd for
> each message that makes up that service. HL7 Wrappers necessarily
> re-describe the Control Act in every message which means that a WSDL
> validator (for example try XML Spy) will reject a WSDL as the combined
> description is trying to describe the same complex type more than once.

so, is there a better way?
The problem is specifying the type of the inner content. Charlie, why
is it that we decided to embed the content when we stitch, instead
of doing it serially? I can't remember

> Question 2 - This would not happen is the transmission information was
> in a separate header. This would allow a WSDL to refer to a generic
> sending header for all messages. Further, this way that the HL7 message
> is necessarily wrapped in a wrapper rather than sat alongside an
> associated header suggests that they were designed for a protocol that
> does not use headers. i.e. putting an HL7 message directly in HTTP
> rather than inside SOAP or any SOAP related protocol such as ebXML or
> WS-Reliable Messaging.
> 
> If InM are revisiting the transmission content I think it is important
> that they make the model a) more flexible with more easily separatable
> transmission information b) contain extensibility elements or - if the
> transmission information is more seperated - at least allow the profiles
> to suggest ways of using the extensibility mechanisms in those
> protocols' headers. The improved relation of HL7 to process choreography
> will be useful too, as currently the concepts of 'trigger events' and
> 'interactions' are as you imply not well aligned with wider facilities
> for process choreography in things like WS-Transactions and WS-Reliable
> messaging.

> I recognise I'm not saying anything revolutionary,

no, this is much more our (INM) direction now. But it's a committee, so
it's not unanimous. Shortly we'll start collecting requirements,
hopefully experts like yourself will be able to contribute here.

Grahame