[New-ITS] Complexity Measures

Thu Aug 31 18:58:50 BST 2006

Rik,

No no please no. Please do not give names to elements just to keep "single
message users" happy. 
It is as I have said earlier building on a mistake I made in supporting the
"clone renaming" camp in MnM a few years ago. We were well-intentioned then
as are today's advocates of extending our folly.

Vendors who support multiple messages will have to learn learn and relearn.
Skilled staff will be have to relearn HL7 to move departments. Certainly the
majority of significant businesses (vendors) and hospitals as consumers will
be in this position (if we ever move close to the CFH vision). Today's
problem is that we have a mix of business names and somewhat primitive
names. So people see something familiar and want more familiar stuff. I
would go 100% primitive on RIM physical class names.

If you think I am wrong consider this. HL7v2 is highly successful with names
that are very limited OBX OBR etc. Why were those implementable when
ActRelationship is not. The reason I think is very simple though I only see
it in retrospect and from some distance. Because if you have 10, 20, 40 or
whatever element names you can document them consistently and once they are
understood they are understood. When you add the next 100 names you think
hey this is great its so friendly. However, the next 100 and the next 1000
and the next 10000 names demonstrate the unscalable nature of the
maintaining consistency if definitions and understanding. In fact well
before you we hit the first 100 the problem appears as people believe their
understanding of the name and ignore any definitions that exist. 

For those wanting to see business names the interesting thing is that going
all primitive on the elements provides a much cleaner environment for simple
tools to render and convert the data for viewing in line with a business
model. Those creating such tools can do so more easily for all the same
reasons noted in the previous paragraph. Continuing to support an increase
business naming in instance data is creating an unmeetable demand and an
illusion of understanding which I think will become more and more an
albatross around our necks.

Kind Regards

David Markwell

Mailto:david at clininfo.co.uk 

  _____  

From: new-its-bounces at lists.hl7.org.uk
[mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Smithies Rik
Sent: 31 August 2006 18:27
To: new-its at lists.hl7.org.uk
Subject: Re: [New-ITS] Complexity Measures

hi,

Complexity isn't the only issue, but when considering it we need to think
about types of users.

An new ITS shaping mechanism will likely add complexity for message
designers, above the RIM-based skills already needed.

It will add complexity for a message consumer/generator who sees messages in
several different ITS flavours (this concerns me most).

It may reduce complexity for a message consumer/generator who only ever has
to deal with messages for a single application domain.
eg a PDS system writer probably doesn't ever need to see act relationships,
and yet the current ITS means they have to be in instances.

cheers,
Rik

  _____  

From: new-its-bounces at lists.hl7.org.uk
[mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of David Markwell
Sent: 31 August 2006 16:59
To: new-its at lists.hl7.org.uk
Subject: Re: [New-ITS] Complexity Measures

Robert

As per my other message to the list I am not saying there is no problem.
However, I do not think the problem is node numbers so much as the
complexity that arises from the multiplicity of different element names that
each require different understanding and management. Thus my sense is that
node variability rather then node count is the bigger issue. 

Any piece of software can process a million bytes in a flash if each one is
processed in the same way but the more exceptions that need to be considered
the more processing becomes capable of error. In my view the really
interesting count would be the number of differently named clones of the
same RIM class that were used with slightly different processing rules. This
in my view is the effect of allowing naming changes etc to be carried from
the business right down to the wire. In this respect I would agree that
within its limits V2 with its OBX and OBR had much merit.

As one of the those who in the past celebrated the idea of being able to
produce some connection between the domain business names and the XML
instances I am by no means feeling smug about this. Instead I am pointing to
what I believe in retrospect was a mistake and arguing following this broad
path (as per recent CFH MIMs "Weight" "BloodPressure", etc) will lead us
further into complexity and chaos. Naturally there is a need to identify
such information at the business level and to indicate how it should be
conveyed - to the extent that general guidance is inadequate for common data
set. However, calling this a different element merely adds another twist to
the spiral of complexity into which we appear to be descending.

  _____  

BTW - I was not arguing for the datatype --> attribute move merely seeing
this as a convenient way to illustrate that decimating the node count may
have no affect on the true complexity.

  _____  

PS:
I am sorry that I probably missed this at an earlier point. However, since
you quote 65,000 after an hypothetical 10 fold reduction this implies you
start out with an example with 650,000 nodes. Could you provide this example
or better still a summary of the information it contains and the
distribution of the node count (i.e.. types of nodes) 

I realise this is information you have probably already provided but if it
is easily to hand it might help me to understand your issues.

Kind Regards

David Markwell

Mailto:david at clininfo.co.uk 

  _____  

From: new-its-bounces at lists.hl7.org.uk
[mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Robert Worden
Sent: 31 August 2006 15:40
To: new-its at lists.hl7.org.uk
Subject: [New-ITS] Complexity Measures

David Markwell wrote:

*       I am far from convinced of the node count as being anything other
than a count of nodes.

He went on to give reasons why node counts as a measure of complexity may be
misleading by factors of the order ten or so, and then went into performance
considerations of DOM and SAX etc. So let me try to clarify why in my view,
both of these arguments miss the point.

V3 has performance issues, but I am far more concerned about the developer
cost of implementing, testing and maintaining messages. If you are worried
about message size, you can always zip them. But I am concerned about why
suppliers have embraced V2, whereas they are hanging back from V3. This
seems to me a much more serious issue for HL7 than performance. Set the
performance issues on one side.

Implementing V3 is hard, in part because the messages are big and complex -
so much so that it is hard for an implementor just to find his way around a
message to find where some data item should be put. This is the needle in a
haystack problem. It seems to me that V2 got this about right, but V3 has
not. 

So I introduced the idea of node count as a measure of the problem. It is, I
know, a crude measure of message complexity, but it is a measure.
Historically, measures of software complexity are always hard to define.
Whether it is lines of code, or function points, or anything else, it is
always possible for someone to say 'your measure misses the point
because..'; 'I could use fewer lines of code, but longer ones' .. or 'I
could cram a big data structure into each XML attribute' or whatever. That
is not the point. If this measure is too crude, please someone suggest a
better one, and post on this list some real numbers for V3 messages in that
measure.  I will bet whatever sensible measure is proposed, the V3 lab
'observation request' will still turn out to be huge. Even with David's
suggestion of cramming every V3 data type into one attribute, it is still
65,000. What V2 message has 65,000 nodes?

I am really not concerned with factors of ten - I am worried about factors
of a hundred or a thousand. My concerns are  on a log scale.  It is all very
well for V3 enthusiasts to say 'It may be big in node count, but it is
really very elegant and if you will only understand it, it is quite easy.' -
but the market does not seem to agree.  We need some way to bridge the
complexity gap between V3 and the applications that will use it. Having a
useful measure of the gap would be a start. Suggestions please.

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/

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060831/6ad75ca7/attachment-0001.htm