[xsd-users] Serialization of inherited class not providing attributes from base class

[roger]

Greetings, 
I am using xsd to generate a Peppol/EHF version 2 invoice based on the
Oasis UBL-2.1 set of schema definitions.   
http://docs.oasis-open.org/ubl/os-UBL-2.1/  (everything is in the .zip
file)
I have successfully used XSD to generate invoices with UBL version 2.0,
but in this version I have hit a snag with a set of attributes that
depend on a base class way down at the bottom of the specifications.
 
In the file UBL-UnqualifiedDataTypes-2.1.hxx, there are a group of
classes defined that inherit from classes of the same name from the file
CCTS_CCT_SchemaModule-2.1.hxx.
example:
UBL-CommonBasicComponents-2.1.hxx has a class that inherits from
CodeType which is in turn inherited from a class in the Invoice
document:
    class DocumentCurrencyCodeType:
public ::UnqualifiedDataTypes_2::CodeType

which is found in:
UBL-UnqualifiedDataTypes_2.hxx:
    class CodeType: public ::CoreComponentTypeSchemaModule_2::CodeType

"CoreComponentTypeSchemaModule_2" is in CCTS_CCT_SchemaModule-2.1.hxx:
This CodeType has an optional listID which is a locally defined typedef
xsd::normalized-string:
 _optional&
    listID ()

Although the .xsd file defines listID as optional, it is required by the
National purchasing authority and the invoices are not accepted without
it.

In my code, I create a CodeType, and populate the listID thusly:
  CoreComponentTypeSchemaModule_2::CodeType krone("NOK");
    const CoreComponentTypeSchemaModule_2::CodeType::listID_type p =
normalized_string("ISO4217");
    //this didn't work either... krone.listID("ISO4217");
    krone.listID(p); 

Then I add it to the Invoice Document as a DocumentCurrencyCode, which
is an "optional but required" element inheriting from
UBL-UnqualifiedDataTypes::CodeType.  
    myxmlfakt.DocumentCurrencyCode(krone);

When I serialize the invoice, I only get:
<cbc:DocumentCurrencyCode>NOK</cbc:DocumentCurrencyCode>

instead of the expected:
<cbc:DocumentCurrencyCode
listID="ISO4217">NOK</cbc:DocumentCurrencyCode>

Can this have to do with the fact that two of the base classes have the
same name, or is it maybe that the inheritance chain is too long? 

Thanks in advance

-- 
Roger Evans, Vitec Autodata Norge A/S mob: +47 93 25 92 36