Thanks for the query. It works great! I understand what youre saying about my XML design. I also understand that the query we're trying to develop is prone to error. Anything unusual will cause errors.
The reason I've structured it this way is because I am going to allow the user to create any levels of sub-accounts. Giving different name for each level of subnode will be like hardcoding i think. I will be allowing the user to go deep into the levels, thats why ive given all the tagnames as Account.. so that I dont have to write a long query which includes names for each level of xml node. On Nov 9, 9:02 pm, Cerebrus <[email protected]> wrote: > 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.
