[New-ITS] Complexity Measures

Thu Aug 31 18:27:13 BST 2006

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/4dd515e4/attachment-0001.htm