[xsd-users] xs:choice representation in C++

[Boris Kolpackov]

Hi Leonid,

Gershanovich, Leonid <leonid.gershanovich at 247realmedia.com> writes:

> When I said that interface is not clear, what I meant is that by 
> looking at accessor signature developer might expect:
> - exception for const reference accessor, when choice_arm points to 
>   another variant arm.
> - and either exception or actually changing variant arm when non 
>   const reference accessor is used, after all following two statement 
>   semantically almost equivalent:
> 
> Obj.stringEl(newVal);
> Obj.stringEl() = newVal;

I agree, for some use-cases this might be the preferred behavior.
However, in my experience, mobile/embedded developers prefer fast,
small, and dangerous to big, slow, and safe ;-)


> Also, how choice arm is initialized in default ctor?

It is in a special, "unset" state.


> And boost::get() does not need to throw exception, as it returns const 
> pointer, thus it can return NULL when uninitialized arm is requested.

I don't see much difference, safety-wise, between forgetting to check
the arm and forgetting to make sure the returned pointer is not 0.
Dereferencing a NULL pointer also results in undefined behavior.


> Does this mean that "full-blown validation" in XSD/e is equivalent to 
> Xerces validation?

Currently XSD/e does not support some of the less commonly used constructs.
For more information see Appendix A, "Supported XML Schema Constructs" in
the Embedded C++/Parser Mapping Getting Started Guide:

http://www.codesynthesis.com/projects/xsde/documentation/cxx/parser/guide/#A


> As right now I rely on Xerces to do validation, including xs:unique, 
> xs:key constraints.

Those are not yet supported by XSD/e.


> If answer to previous question is yes, then my next question would be - 
> why keep Xerces support?

While validation in the generated code has its advantages, having it
at the "lower level" makes the architecture much more flexible. Some of
the very powerful mechanisms in C++/Tree, such as type customization,
typeless content handling, and XPath execution are possible because of
the use of the DOM representation and validation in the underlying XML
parser.


> > It is also a partial solution that can only address some choice use-
> > cases, as I showed in my previous email.
>
> I do not exactly understand that do you mean? It seems to me that all 
> use cases from you previous emails can be covered by boost::variant + 
> overloaded accessors. Am I missing something?

I was referring to the fact that you will still have to generate nested 
classes for more complex situations. And if we are going that route, we
might as well do it for simple cases and provide an interface that is 
more convenient to use. This is what we did in XSD/e.  This is, of 
course, assuming you agree with me that the C++/Hybrid mapping for 
choice is better than boost::variant ;-).

It seems to me that the only advantage boost::variant's safe (but
heavy-weight) interface has is that the compiler will complain if
you forget to handle some arms. Some compilers (e.g., g++) warn you
if you don't handle all enum values in a switch statement. So if you 
use switch to handle the values, then you can get a similar level
of safety.

Also, your statement about overloaded accessors got me thinking about
a situation like this:

<choice>
  <element name="foo" type="string"/>
  <element name="bar" type="string"/>
  <element name="baz" type="int"/>
<choice>

That is, you have two choice arms with the same type. I don't think
boost::variant will be able to handle this (i.e., which arm will
boost::get<string>() return?)

Boris