dynamic naming for hierarchical problem

[Peter Hansen]

Jeremy Jones wrote:
> 
> In the example that I was working on, the children (not of the same parent,
> but in different tiers of the hierarchy) were of differing types and would
> have different attributes and different quantities of attributes.  I don't
> know if I spelled that out exactly like that initially, but immediately
> under the root would be test sets.  The test sets right now don't have any
> attributes of their own, but they do have children - tests.  The tests would
> have an attribute of pass/fail and a reason why and commands as children.
> The commands would have attributes of expected result, pass/fail, actual
> result.  I suppose you could hack together a table that would accomodate all
> of those different attributes and have CHILD as a foreign key, but it seems
> it would be a pain to give it room to grow if I needed it to.  
[...]
> I appreciate the posts.  They have definitely spurred me on to think
> differently.  I am still inclined to think that the DOM/XML route will be a
> more simple route for my specific problem.

One of the reasons I suggested the XML route is this.  Over 
the last year and a half, one of our projects has been the 
development of an automated factory test system.  It interfaces 
with instruments using GPIB and executes a variety of tests 
on the device under test (DUT).  All results are written out 
as XML.  The input is (currently partially) XML also.  One 
of the primary requirements leading to the choice of XML was the
expectation that we would have substantial growth and change 
over the first implementation.  By using XML, we handle this 
easily.  (Coincidentally, although our input doesn't have 
pass/fail, the output has an <outcome> element which contains 
PASS or FAIL or COMPLETE and an optional element <reason> which 
contains text describing why a test failed, sort of as you were 
thinking.)  The code, of course, is in Python (with calldll).

Another reason I keep picking XML for this kind of thing is that
I can gradually leverage more and more all these tools being 
developed for XML processing.  If I need to compare two XML 
trees... hey, somebody just made Xmldiff 
(http://www.logilab.org/xmldiff/ ... thanks Alexandre! :-) 
and that will do the trick.  If I need to display it 
quickly I can just fire up IE (ugh).  If I want to print
it, I can write some XSL stuff with FOP to convert to
PDF.  And if I need to edit the data by hand (and sometimes 
I still do), I can fire up a Plain Old Text Editor.

Although there are some limitations relative to other, 
special-purpose or more mature technologies, the synergy
I'm beginning to see with all these tools and standards 
is really starting to prove (at least to me) the sheer
power of a universal standard which is general enough to
adapt and handle diverse applications.  A relational 
database might give you better performance.  Maybe even
a slightly simpler solution -- for now.  When you look back
after a year and see how warped your system has become
because of this initial choice of a "brittle" solution,
you might rewrite with XML (or something else) anyway.

(Of course, follow XP principles regardless: if you
have to spend significant time learning and implementing
the solution with XML, don't go there.  Just pick something
simple, as Alex said and you agreed, and get it working.
You can always plan on refactoring once the basic thing
is working and you can focus on learning XML without the
pressures of trying to make the system work at the same 
time.)

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com