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

Wed Sep 20 11:37:51 BST 2006

Joe

That is why we need you to remain engaged as the debate is revisited in
the light of experience five years on -- and I think that both
experience and shifts in the underlying technology make it easier to
spot where the separations should be -- as INM develop the new transport
models I expect them/us to come up with something closer to the SOAP
paradigm.  It seems likely that we will get another 7 years of use out
of the new specifications, so it is important to feed into them
effectively and efficiently, and I see your "wrapperless world"
presentation as a valuable bit of evidence to contribute

All the best

Charlie  

Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D
Dogpole, Shrewsbury, Shropshire SY1 1ES
tel 01743 232278 / 07808 570172  skype: charliemccay

> -----Original Message-----
> From: joseph.2.waller at bt.com [mailto:joseph.2.waller at bt.com] 
> Sent: 20 September 2006 10:17
> To: Charlie McCay; grahame at jivamedical.com
> Cc: new-its at lists.hl7.org.uk
> Subject: RE: [New-ITS] [New ITS] - Industry Tool Support
> 
> Charlie,
> 
> It sounds like a reasonable debate took place. Though 
> personally I would still have voted the other way. It's 
> better to allow all possible implementations to work with 
> some imperfections around representing semantic dependency, 
> rather than having schema that simply don't lend themselves 
> to certain implementations.
> 
> Alternatively, rather than representing transmissions as...
> 
> <Wrapper>
> 	[Attributes]
> 	<Control Act>
> 		[Values]
> 		<Subject>
> 
> You could represent it...
> 
> <Wrapper>
> 	<Transmission Data>
> 		[InteractionId]
> 		[Other Attributes]
> 	<Control Act>
> 		[Values]
> 	<Subject>
> 
> With the interaction Id repeated as an attribute. This would 
> allow SOAPY implementers to use a separate header with less 
> deconstruction of the standard HL7 representation. I guess 
> this is the 'wrapperless world'
> debate that we presented a while ago.
> 
> Regards,
> 
> Joe
> 
>  
> 
> -----Original Message-----
> From: Charlie McCay [mailto:Charlie at ramseysystems.co.uk]
> Sent: Tuesday, September 19, 2006 10:24 AM
> To: grahame at jivamedical.com; Waller,J,Joseph,JPGA3Y C
> Cc: new-its at lists.hl7.org.uk
> Subject: RE: [New-ITS] [New ITS] - Industry Tool Support
> 
> 
> Comments inline
> 
> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D
> Dogpole, Shrewsbury, Shropshire SY1 1ES
> 
> tel 01743 232278 / 07808 570172  skype: charliemccay
> 
> 
>   
> 
> > -----Original Message-----
> > From: new-its-bounces at lists.hl7.org.uk 
> > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of 
> Grahame Grieve
> > Sent: 19 September 2006 00:55
> > To: joseph.2.waller at bt.com
> > Cc: new-its at lists.hl7.org.uk
> > Subject: Re: [New-ITS] [New ITS] - Industry Tool Support
> > 
> > 
> > 
> > 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
> 
> We did try to move to the headers paradigm in one of the later ballots
> of the XML Structures ( maybe Ballot 7 of 10) but it was voted down on
> the basis that it did not cleanly reflect the semantic dependancy,
> creating an arbitary fixed break between what belonged to the 
> header and
> what belonged to the payload.  By using containment the receiver could
> ignore the boundary and process the entire transmission as a 
> single RIM
> graph.  It is also possible to create schemas to recognise just the
> transport, or transport+controlAct wrappers, and have xsd:any for the
> content -- thus supporting a generic WSDL that passes the 
> processing of
> the inner message on to some other process behind the interface.  The
> HL7 publication has been structured to allow for such schemas to be
> generated -- just that no-one has had the resource/drive to get them
> produced. That is how the discussion went that carried the committee
> against the use of headers.
> 
> The WSDL combination problem should be resolved now -- I have not
> checked it recently, but I know that there was a problem with multiple
> includes of the same file (which should be allowed) causing validation
> errors with some processors, and also with some unused types causing
> errors with some processors.  Both issues could be addressed by either
> doing some tweeks to the schemas, or improving the 
> processors, or both.
> CFH have taken their schema support in-house, and Lloyd has been
> maintianing the schema generator, so I am not as close to 
> this as I once
> was...  
> 
> 
> > 
> > > 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.
> 
> Agreed - it makes a huge difference when there is direct input from
> those with direct experience
> 
> > 
> > Grahame
> > 
> > _______________________________________________
> > New-ITS mailing list
> > New-ITS at lists.hl7.org.uk
> > http://lists.hl7.org.uk/mailman/listinfo/new-its
> > 
> > 
> 
> 
> 
> 