[xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements

[Wheeler, Bill NPO]

Boris,

   Thanks for your response.  The reason I want to generate the base class version is because my actual X_root class is way more complex than the simplified example we've been discussing.  Thus I'd like CodeSynthesis to do all the heavy lifting for me by generating most of the code in the base class.  So that's why I ask the question about the flag setting to disable base class parsing being invoked from the base class constructor.  More specifically, the reason I asked the flag setting question is I wasn't sure if there would be other unintended functional artifacts by passing "(f | xml_schema::flags::base)" in to the base class.  From your response, I presume this is not a problem.

   Thanks again for your thorough response...I very much appreciate it.

Bill

-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Sent: Tuesday, November 09, 2010 8:51 AM
To: Wheeler, Bill NPO
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements

Hi Bill,

Wheeler, Bill NPO <bill.npo.wheeler at intel.com> writes:

> When this calls into the C_container_base version of the constructor, 
> I want the value of "f" to be such that it does not invoke the base 
> class version of the parse method, because I will customize the parse 
> function in the C_container class.

If you pass (f | xml_schema::flags::base) to the base c-tor in which
case it will not perform any parsing.

But I think the better way to achieve this is not to generate the base 
class at all. You don't need the generated parsing/serialization code
and it will be easier to come up with a custom interface for accessing
elements rather than trying to complete the generated interface with
some kind of order lists, etc.

Here is how I would handle this:

1. Completely customize the X_root type (i.e., don't generate the base
   type). The custom X_root interface would look along these lines:

class X_root: public ::xml_schema::type
{
public:
  struct choice_element
  {       
    enum arm_tag
    {
      A_tag,
      B_tag
    };

    arm_tag
    arm () const
    {
      return arm_;
    }

    A_elem& a (); 
    B_elem& b (); 
    
    // Constructors
    //
    choice_element (A_elem* a)
      : arm_ (A_tag)
    {
      element_.a = a;
    }

    choice_element (B_elem* b); // Same as above.

    // Copy c-tor, copy assignment operators, and d-tor
    // implementations are straightforward.
    //

  private:
    arm_tag arm_;
    union
    {
      A_elem* a;
      B_elem* b;
    } element_;
  };

  typedef std::vector<choice_element> choice_sequence;
  typedef choice_sequence::iterator choice_iterator;
  typedef choice_sequence::const_iterator const_choice_iterator;

  choice_sequence&
  choice ();

  X_root ();

  X_root (const xercesc::DOMElement& e,
          xml_schema::flags f = 0,
          xml_schema::container* c = 0);

  // The rest of the c-tors as in the generated code.
  //

private:
  choice_sequence choice_;
};

void
operator<< (xercesc::DOMElement&, const X_root&);
 
2. In the parsing constructor iterate over DOM elements and parse
   each either as A or B depending on the name (you can copy most
   of the code from the generated version).

3. In the serialiation operator iterate over the choice sequence
   and serialize each element as either A or B depending on the
   arm tag. Again, you can copy most of the code from the generated
   version.

Boris