[New-ITS] Reshaping should be at the discretion of an implementor
Robert Worden
Robert.Worden at Charteris.com
Mon Sep 4 21:45:01 BST 2006
Grahame -
You seem to be saying: local reshaping may have its uses, but it is an
implementor thing, not a standards activity, so it does not belong in a
standards project, which the new ITS project is.
I think we can agree that standards are for implementers. But I don't
want to debate the right scope for the new ITS project.
I will be perfectly happy if the use of local XUMs as intermediate XMLs
is regarded as a spinoff from the new ITS project, rather like Teflon
from the moon-shot.
Do you want to take a giant step for mankind, or just fry eggs? Now you
can do both...
Robert
Charteris plc, Charteris House, 39/40 Bartholomew Close, London
EC1A 7JN
phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970
197968
*************************** E-mail confidentiality notice
*******************************
This message is intended for the addressee only. It is private,
confidential and may contain
information of a proprietary nature. If you have received this message
in error, please notify
us and remove it from your system.
-----Original Message-----
From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame
Grieve
Sent: 04 September 2006 08:05
To: Robert Worden
Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk
Subject: Re: [New-ITS] Reshaping should be at the discretion of an
implementor
Robert Worden wrote:
> Grahame -
>
> You wrote:
>
>> Reshaping - while useful as an implementation tool - is
>> not going to help with interoperability, unless we can get
>> a single basis for reshaping
>
> I disagree!
actually, you agree, nearly. You describe a whole lot of uses of
reshaping that are *implementation tool* usages - and they all make
sense.
Then you assert that
> Only send reshaped message instances between consenting
> parties, who have agreed to use the same reshaped model.
well, perhaps. In fact, fine. But it's not going to help us
find an ITS that is useful - which is what we are about here,
and nor is it an appropriate thing to engage in at the standards
level. In fact, in the end, all of the optimisation things die
at the standards level because they make operability easier
but interoperability harder.
Grahame
> Suppose I use a reshaped and restricted RMIM, purely as a way to get
> full-ITS V3 onto the wire (not to reveal reshaped instances in
public).
> I use the reshaped model only as an intermediate step between my
> application and V3. Then:
>
> - Because the reshaped model is smaller and simpler than the RMIM, and
> has business names, I make more accurate mappings onto my applications
>
> - Because the mappings of the reshaped XML onto V3 are
> machine-generated, not hand-coded, there is no potential for error in
> translation from reshaped XML to the full ITS
>
> - Therefore I have a more error-free interface between my applications
> and V3 full ITS
>
> Surely that is 'going to help with interoperability'? And it does not
> need a single basis for reshaping in order to work. If you don't think
> so, Grahame, please tell me why.
>
> (I am genuinely perplexed at my failure to explain this point to some
> very clever guys like you!)
>
> In using reshaped models like this, I would only be following the
> advice on the HL7 Implementation Wiki:
>
> 'Do add a layer of abstraction, in the form of an intermediate XML
based
> format, and map this to HL7 v3 artefacts, e.g. with the aid of a
> stylesheet. The structure of the intermediate format should be the
best
> possible mix of the internal database format and the model used by
> CDA/Clinical statements.'
>
> Or:
>
> 'If you are working with XSLT you need to define an intermediate XML
> format for your data. This can be in "close to HL7" form or in "close
to
> native" form.'
>
> HL7 does not require standardization of the intermediate XMLs.
>
> Only when you go to the next stage, of sending reshaped instances over
> the wire, do you get interoperability issues. My solution to these
> issues is: Only send reshaped message instances between consenting
> parties, who have agreed to use the same reshaped model. If either
party
> wants to use full XML ITS, the other party has to provide it. And he
can
> do so, because he has an accurate transform to do it.
>
> (This next stage is not necessary, unless you are concerned about
> performance and small message instances)
>
> Again - have I somehow failed to explain this point to anybody else on
> the planet? What is wrong with it?
>
> Grahame - I think the key to your objection may be where you say 'it's
> not going to solve problems at the level of the standard'. Maybe it
> doesn't need to. Perhaps we should distinguish between (a) practical
> things that implementers can do now, and (b) proposed changes to the
> standard. We can propose a mix of these if we want to.
>
> Best wishes
>
> Robert
>
> Charteris plc, Charteris House, 39/40 Bartholomew Close, London
> EC1A 7JN
>
> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970
> 197968
>
> *************************** E-mail confidentiality notice
> *******************************
>
> This message is intended for the addressee only. It is private,
> confidential and may contain
> information of a proprietary nature. If you have received this message
> in error, please notify
> us and remove it from your system.
>
> -----Original Message-----
> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame
> Grieve
> Sent: 04 September 2006 05:53
> To: Robert Worden
> Cc: new-its at lists.hl7.org.uk
> Subject: Re: [New-ITS] Reshaping should be at the discretion of an
> implementor
>
> hi
>
> I think this should be rephrased as, "implemention
> should be left to the implementor".
>
> No one (I hope) would disagree with this.
>
> Reshaping - while useful as an implementation tool - is
> not going to help with interoperability, unless we can get
> a single basis for reshaping - and suddenly we are back to
> where Charlie was.
>
> So what would actually be useful is a tool - or set of tools - that
> can take an RMIM, and a profile on the RMIM - and produce useful
> implementation constructs, and then this can be offered to the
> implementors to help them implement.
>
> Robert, your tool is a step in the right direction here, and
> a laudable direction - but it's not going to solve problems
> at the level of the standard, I think.
>
> The hard part is doing the profiling
>
> Grahame
>
>
>
> Robert Worden wrote:
>> All -
>>
>>
>>
>> Allow me to dissent from a prevailing view about
flattening/reshaping,
>> as expressed by Charlie:
>>
>>
>>
>>> I think that you are proposing naming different sets of rules for
>> different degrees of flattening etc.
>>
>>> This is going too far, and that if flattening is to happen we will
> have
>> to agree on one set of rules+annotations that can be used.
>>
>>
>>
>> I think if we try to agree any set of rules that must be applied,
then
>> the reshaping will not achieve one of the main aims of the project -
> to
>> reduce complexity for developers.
>>
>>
>>
>> As a crude measure of developer-perceived complexity, I use 'node
> count'
>> - the number of distinct nodes in a message definition tree, allowing
> no
>> repetitions or self-nesting.
>>
>>
>>
>> V3 node counts are very big. For a basic PA 'new Person' message, the
>> node count is 1,129 (cutting off at V3 data types) or 77,550 (going
to
>> the leaves of the XML tree). For the lab 'Observation request'
message
>> the node count is 65,031 (going down to V3 data types) or 4,414,328
>> (going to leave of the tree).
>>
>>
>>
>> For a developer who wants to convey, say 100 data items in a message,
> he
>> has to find the right V3 nodes amongst these thousands or millions to
>> map onto - like a needle in a well-structured haystack. There is a
> huge
>> impedance mismatch between his application and V3 (as between a
> domestic
>> kettle and the national grid). That is why suppliers don't do it,
> unless
>> someone pays them to.
>>
>>
>>
>> One of the main aims of flattening/reshaping is to reduce the
> impedance
>> mismatch for developers.
>>
>>
>>
>> Flattening one association in a message definition will reduce the
> node
>> count by precisely 1. Flattening on its own does nothing to reduce
>> complexity as perceived by developers - it has no perceptible effect
> on
>> node count, and it removes a lot of the tree structure which helps
>> people find their way around (it makes the haystack less well
>> structured, but does not reduce its size).
>>
>>
>>
>> Flattening and renaming is only effective when done in combination
> with
>> restricting the RMIM, to reduce the node count. This cannot be done
in
>> any automatic way, or in a way decreed by HL7 committees - it has to
> be
>> done by a super-implementor like CfH, knowing the applications they
> need
>> to integrate.
>>
>>
>>
>> My proposal is to give implementers complete freedom to flatten,
>> restrict and reshape as much as they like, to make messages which
work
>> for them and can be mapped to easily by their suppliers. These
> messages
>> can always be reflated to fully compliant V3, using reliable
automatic
>> translation based on the mappings. Implementors can produce full V3
on
>> demand, but don't need to send it always over the wire.
>>
>>
>>
>> Put another way: producing V3 via an intermediate XML is what HL7
>> already encourages implementers to do. A reshaped, flattened ITS is
> just
>> such an intermediate form. We are just telling HL7 that an
> implementor,
>> with a group of communicating applications, may choose to use the
>> intermediate form over the wire between those applications, and only
>> produce full V3 on demand, eg to prove conformance, or to communicate
> to
>> other applications outside his group. HL7 should be constraining the
>> semantics of what goes over the wire, not its physical form.
>>
>>
>>
>> (And if you are worried about performance costs of reflating to full
> XML
>> ITS - performance is an implementor issue. Let implementors solve it
> as
>> they think fit - not by decree from HL7)
>>
>>
>>
>> Robert
>>
>>
>>
>> Charteris plc, Charteris House, 39/40 Bartholomew Close, London
>> EC1A 7JN
>>
>>
>>
>> phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970
>> 197968
>>
>>
>>
>> *************************** E-mail confidentiality notice
>> *******************************
>>
>>
>>
>> This message is intended for the addressee only. It is private,
>> confidential and may contain
>> information of a proprietary nature. If you have received this
message
>> in error, please notify
>> us and remove it from your system.
>>
>>
>>
>>
>> _________________________________________________________________
>> This message from Charteris plc has been checked for viruses
>> http://www.charteris.com/
>>
>>
>>
>
------------------------------------------------------------------------
>> _______________________________________________
>> New-ITS mailing list
>> New-ITS at lists.hl7.org.uk
>> http://lists.hl7.org.uk/mailman/listinfo/new-its
>
--
Grahame Grieve
CTO, Jiva Medical Software Integration Tools
CTO, Kestral Computing Healthcare Applications
_________________________________________________________________
This message to Charteris plc has been checked for viruses
http://www.charteris.com/
_________________________________________________________________
This message from Charteris plc has been checked for viruses
http://www.charteris.com/
More information about the New-ITS
mailing list