The redesign of this XML depends on a variety of factors, actually, such as the data structure from which the XML is created, but more so on the mode of data retrieval. I would restructure the XML so that node names at each level are indicative of their position in the hierarchy. Any summation is operative only on that level at a time.
The way the XML is currently structured, parent, child and grandchild nodes have the same name. Therefore, you will need to fully qualify any XPath aggregation statements. Unfortunately, the sum() for Account with Code=4000 will result in NaN because the Account with Code=4003 does not have a value (it contains child nodes, instead). Therefore, you would have to design an XPath that checks if the current Account node has child nodes or not and only process it's value if it does not. For instance, the following XPath expression will retrieve the correct value for both the cases you described: (Note the double slash before the second Account node) --- sum(/Accounts//accou...@code='4000']/descendant::Account[count (child::Account) = 0]) = 50760 sum(/Accounts//accou...@code='4003']/descendant::Account[count (child::Account) = 0]) =11100 --- Put in words, the XPath would be: "Find the sum of the InnerText of all Account nodes which have a Code = 4000 and also any descendants which do not have further Account children." This works, but it is ugly and prone to error. On Nov 9, 6:14 pm, Faraz Azhar <[email protected]> wrote: > :D > Cerebrus.. kindly advise me what is the right way to design this XML. > I thought I had a good design, considering plenty samples across the > net. But when I see the functions XML can perform, i often realize > that there is more to XML than what I am creating. So kindly advise > what kind of structure would suit good? > > If you notice, my XML stores some accounting records. Like a financial > balance sheet. There are assets and liabilities in it. Then accounts > and sub-accounts, all have values in them. So I need the power of fast > summation of these values. >
