[xsd-users] Seperation of Data and serialization code

[Boris Kolpackov]

Hi Shiva,

Balasubramanyam, Shivakumar <sbalasub at qualcomm.com> writes:

> IMO, constructors that accept parsing objects (like :xercesc:DOMElement)
> could also be implemented as operators that can reside in a different
> file or library, which will be used by serialization feature.

I probably haven't explained the problem with this approach well enough
in my previous email. Let's assume we have the following type:

<complexType name="name">
  <sequence>
    <element name="first" type="string"/>
    <element name="middle" type="string" minOccurs="0"/>
    <element name="last" type="string"/>
  </sequence>
</complexType>

The first and last elements are required and it is a good idea not
to allow construction of the name object without these two values
specified. To achieve this, XSD won't generated default c-tors for
such objects (unless you explicitly request them with the --generate-
default-ctor option). The only c-tor (besides the copy and parsing
c-tors) that will be available for this type is the following:

class name
{
  name (string first, string last);

  ...

};

As a result you cannot do something like this:

name n;

Instead you are forced to do:

name n ("John", "Doe");

Now suppose we got rid of the parsing c-tors and instead make them
operators in the form:

void
operator>> (DOMElement&, const name&);

When we (or the generated code) use this operator, we need to construct
the object first:

DOMElement& e = ...

name n;
e >> n;

The default c-tor is not available which forces us to either provide
the default c-tor which makes the object model easier to misuse or
write something like this which is slow and ugly:

name n ("", "");
e >> n;


> Could you please elaborate on the role of global functions? Are these
> basically the registration or mapping of XML nodes to serialized class
> types?

Global functions correspond to the global elements and are just helper
functions that allow you to parse XML from common sources.


> I am sure this is really challenging problem for implementation.

The major problem with implementing this is two-fold:

1. The object model becomes "looser" as explained above.

2. The parsing c-tors are part of the interface and are used, for
   example, to parse wildcard content. Removing these c-tors will
   break user code.

Overall, I tend to think that change of a format (e.g, from XML to
binary) does not happen very often to warrant breaking of the
interface and making the object model less strict. What do you
think?

Boris