Maybe I'm doing drugs (well, that's a gimme but I'm referring to more interesting drugs), but that looks like a pretty straightforward XML schema to me. The xxBALCALC schema element corresponds to a SQL table, the BALCALC element corresponds to a row, and the individual sub-elements inside of BALCALC are all present in every BALCALC element. Unless I'm missing something, that is about as regular as XML gets, and a near perfect translation of the rectangular row/column view of data used by SQL.
XML definitely is an EAV scheme, that is part of its design (in other words a feature, not a bug). That particular XML schema is perfectly regular, no sub-elements change from one element to the next as far as I can see.
Is what you are trying to tell me that the DATAKEY values are actually EAV attribute names stored inside of the XML rather than being simply data?
Just curioius, but when I create XML I usually use an application or script to do it rather than trying to build the XML directly from a database query. Even if you choose to build the XML using a cursor in Transact-SQL, this is just sinfully ugly, not hairy to do...
Just so I understand, you're wailing about the ugly factor, not complaining because of difficulty, correct?
Just found out my client requires our application to export this data for import into their data warehouse: ... Look at it. That's right. Its EAV in XML. I'm going to go cry in a corner for a while....
I'm on record here as complaining about EAV... but only as a storage mechanism and a permanent structure. (Because it makes queries a PITA and because you can't impose integrity constraints on it.)
But for transmitting data, it makes sense. You could pretty much do a one to one translation of BALCALC elements to SQL statements for importing.