[New-ITS] Reshaping should be at the discretion of animplementor
Robert Worden
Robert.Worden at Charteris.com
Mon Sep 4 21:44:54 BST 2006
Rik -
Like my other interlocutors, you make a good point. The freedom to
reshape an RMIM may not take you far enough to make the local XUM quite
as suitable as a less-constrained intermediate XML. Or it may, in a lot
of cases - we just need to try it out a bit. My experiments persuade me
you can do quite a lot.
However, suppose the XUM does not go far enough towards some
application's own data model. (As I now see you have already spotted)
they could still define another intermediate XML, closer to their own
data model, and map that onto the XUM rather than onto the RMIM - in
effect going via their own intermediate XML, and the XUM, in series.
Now in case you think that would be a bit elaborate and error-prone:
- because the XUM-to-RMIM mappings are made automatically and are
error-free, the extra stage of translation will not add errors
- because the XUM is smaller and closer to their business names than the
RMIM, their mappings to the XUM will be more accurate than mappings onto
an RMIM - reducing errors
- they do not even need to have two stages of physical translation; by
mapping their own intermediate XML onto the XUM object model, they can
generate one XSLT which wraps up both stages of translation, accurately
('own => RMIM' fully equivalent to 'own => XUM => RMIM'). In effect, the
XUM would then never be visible in instances. That might make some
people happy.
So there are a lot of ways to use local XUMs. We need to get experience
of them.
In the 'national grid' analogy, if the application is a kettle at 240V
and V3 is the national grid at 132,000V, you may introduce several
transformers to bridge between the two - especially if one of the
transformers is guaranteed to be loss-free.
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: Smithies Rik [mailto:rik.smithies at cfh.nhs.uk]
Sent: 04 September 2006 12:28
To: Robert Worden
Cc: new-its at lists.hl7.org.uk
Subject: RE: [New-ITS] Reshaping should be at the discretion of
animplementor
Hi Robert,
on the specific point of using the collapsed model as your intermediate
XML format, which I only appreciated in your last post, I think that is
a little bit of a stretch.
The intermediate for an implementer uses may be something close to their
existing data structure.
This will be quite different from the message format, and different from
the receiver's data format, and hence their intermediate XML.
If the intermediate format is defined by the message modeller, who may
not be aware of either party's format, then it may not be a good fit.
So you would probably end up defining another intermediate layer, which
is then mapped to the collapsed model format.
Now, there is some merit here that the collapsed model may have removed
some of the perceived "HL7 junk", defaults, unfamiliar names etc and so
be easier to target. These are the proposed benefits of the collapsed
model that we are discussing.
But I'm not sure we can go further and expect this model will just slot
in as the intermediate format for many implementers.
cheers,
Rik
> -----Original Message-----
> From: new-its-bounces at lists.hl7.org.uk
> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden
> Sent: 04 September 2006 07:41
> To: grahame at jivamedical.com
> Cc: new-its at lists.hl7.org.uk
> Subject: Re: [New-ITS] Reshaping should be at the discretion
> of animplementor
>
> 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!
>
> 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/
> _______________________________________________
> New-ITS mailing list
> New-ITS at lists.hl7.org.uk
> http://lists.hl7.org.uk/mailman/listinfo/new-its
>
This e-mail is confidential and privileged. If you are not the intended
recipient please accept our apologies; please do not disclose, copy or
distribute information in this e-mail or take any action in reliance on
its contents: to do so is strictly prohibited and may be unlawful.
Please inform us that this message has gone astray before deleting it.
Thank you for your co-operation.
_________________________________________________________________
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