Although I did use test data almost identical to yours, any similarity between the code I posted and the code you posted is purely coincidental. It's *supposed* to be different, otherwise why post it? That's the whole point. Please note I was responding to the OP, which did not specify a problem domain. Hats off to you for the additional features and assumptions you added in for free on his behalf *applause* ... This brings us to our regularly scheduled standard disclaimer for today...

Standard Disclaimer For Posted Code:

• without warranty regarding claims to completeness, fitness or reliability
• make no assumptions about the given problem domain, unless explicitly stated in the OP
• are offered as free-of-charge food-for-thought
• may not have anything to do with what a reasonable person might expect, and might even be a total red herring, and worth less than the zero Euros you paid for it
• caveat emptor

This is a minor philosophical consideration, totally unrelated to the OP, but relevant to tachyon's comment, hence the additional node.

If you have heard of the MVC paradigm, you probably are familiar with the basic goals of that programming model. I tend to use a paradigm that is somewhat similar to MVC. Specifically, one of the basic 'rules' is as follows:

Always make a clear separation between code that *creates* data fields (aka the 'M' part), and code that *outputs* those data fields into a 'fill in the blank' style template (aka the 'V' part).

Given this approach, perhaps it becomes evident why someone would segment out code into separate subroutines, and why one subroutine would expect to get its data fields in prefectly segmented 'widgets' for spitting out a template (and a different subroutine would do the proper 'munging' to make sure they are perfectly segmented).

Then again perhaps it doesn't become evident. Oh well. FWIW. YMMV. Thanks for coming to the show. Please tip your waitress generously. Have a nice day.