Bug in XSU: @ttributes don't work more than once

Question

This was a nettlesome one to diagnose and workaround. The fix is easy, but Oracle doesn't ship their source code, so someone there will have to do it for us.
Recent releases of the XSU have a feature where you can output XML attributes, rather than the "canonical" elements, by using column aliases prefixed with "@" i.e. "@myCol". This is great as the canonical approach is quite wasteful in bandwidth: <myCol>...</myCol> vs. myCol="...".
So what I do is create object types with attributes named "@myAttr" like so:
create type MyDisplayer_objTyp as object ( "@myAttr" varchar);
And I can put these in other object types for compositional purposes:
Create type MyOverviewDisplayer_objTyp as object ( "myNs:myDisplayer" MyDisplayer_objTyp);
And this works great, the first time it's recognized by the XSU:
<myNs:myOverview><myNs:myDisplayer myAttr="myValue"/></myNs:myOverview>
So far, so good. The problem is, any subsequent appearance of MyDisplayer_objTyp in MyOverviewDisplayer_objTyp will generate the canonical element form for myAttr! And it will do so without even outputting the "@" prefix:
Create type MyOverviewDisplayer_objTyp as object ( "myNs:myDisplayer" MyDisplayer_objTyp, "myNs:myDisplayer2" MyDisplayer_objTyp);
Should generate:
<myNs:myOverview><myNs:myDisplayer myAttr="myValue"/> <myNs:myDisplayer2 myAttr="myValue2"/></myNs:myOverview>
But remarkably generates this instead:
<myNs:myOverview><myNs:myDisplayer myAttr="myValue"/> <myNs:myDisplayer2><myAttr>myValue2</myAttr></myNs:myDisplayer2></myNs:myOverview>
So what is happening here? I can see the error, and I can see how this never got included in a test suite. The test suite didn't feature redundant inclusions of the same object type, creating the bug where it only works the first time.
What no doubt happened when they put in this "@" trick was they stored whether or not to generate an attribute in a local variable, but they put the attribute name into an object that is cached for future occurrences of that type. The fix is to put that local variable into the object definition so that it rides alongside the attribute name, and the system knows to generate an XML attribute for that value rather than the "canonical" element form that it is generating the second (and all subsequent) times through.
The iterator for collection types must be within the scope of this local variable, as all elements of a collection are generated properly, provided the collection is the first time the object type is encountered. (BTW, is there any way we can suppress or rename that myCollection_ITEM gunk, so we can generate XML that no one can tell came out of the Oracle XSU? Please?)
The only workaround I could find was creating duplicates of those types, named MyDisplayer_objTypA, MyDisplayer_objTypB, etc. and declare those instead of just the same type. This resets that local variable in the XSU code and the output works…but at great cost of development time and runtime!
I am using XSQL to test the XSU here; if you can't reproduce it with just the XSU try in XSQL, but I doubt the problem has anything to do with XSQL.
Thanks for your attention to this bug. Please let me know if there’s a better known bugs list somewhere accessible to the public if you would like more of these reports, without redundant reporting.
Peter Jensen

Answer 1

Oh and before you tell me to just use XSLT on the output to get it how I want it, or use XMLType views where the XML is generated on the database server, I can assure you I know both of those options, but they both cut into the profitability of running a high-volume service.
The XSU (XML SQL Utility for those keyword searching) is great in that I can host it on middle tier servers in any servlet container and take the burden of XML generation and parsing off the $40K/processor server. If I can further take the burden of XSLT transformations off the middle tier, so much the better... The XSU allows me to run the same throughput on probably something like half the hardware and a tenth the licensing fees.
So here's a huge vote in favor of continued development of the XSU...I would also like it to handle XML attributes on inserts/updates rather than having to use the "canonical" element form.
If anyone knows an even better approach, please speak up!