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

[Boris Kolpackov]

Hi Leonid,

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

> However, in second case, I cannot imagine why developer might want to have 
> flatten representation in c++ code, after all, developer can always make 
> his schema in such a way that c++ code is simpler.

In my experience, in situations where flattened API causes problems, 
generating C++ code from schemas is a secondary concern. The primary
concern is usually to make the XML documents have a certain structure 
and/or to capture all the constraints.


> >> While this API preserve the structure of the content, the flat API is
> >> probably preferable in this case since all one needs is a list
> >> of to's, cc's and bcc's.
>
> This is not 100% true. By giving such lists you lose order of 
> appearance in original xml, which might be significant.

Well, in this specific case, order for "to", "cc" and "bcc" elements is
obviously not important. Most cases that I have seen would fall into
this category.


> 1. while it is clear that calling "void intEl (int);" should change 
>    choice_arm and set int value, what should happen when "int& intEl ();" 
>    is called?

That would be illegal (undefined behavior). We could have thrown an
exception but that is an Embedded mapping so we kept it minimal. 
boost::get() probably also throws an exception if you try to access
the wrong variant arm.


> 2. furthermore, what should happen when "int intEl () const;" is called 
> while choice_arm() is set to stringEl_tag ?

Ditto.


> It seems that while such structure seems suitable for data retrieval, it 
> seem to allow setting both choice arms in case when I am setting up object 
> for later serialization. 

No, it doesn't. Only one choice arm can be effective at any given time.


> boost::variant has cleaner interface in that sense

How so?


> Also, can you please clarify for me if it is possible to get "Compositors"
> generated code (nested classes for xs:sequence, xs:choice and xs:all) while 
> using "CodeSynthesis XSD" with "C++/Tree" mode?

No, C++/Tree only supports the flattened mode. The major problem with 
supporting the structured mode is that you need full-blown validation
in the generated code to properly associate elements and attributes
to class members during parsing. C++/Tree delegates validation to the
underlying XML parser. Maybe we could use PSVI for that though I am 
not sure there will be enough information.

Note also, that while XSD/e if primarily targeted at mobile/embedded 
systems, nothing prevents you from using it on general-purpose 
platforms.


> I do agree that using boost::get is very close to what is possible now. 
> But developer would have a choice: either use boost::get ("light" 
> accessor) or "heavier" solution. Right now there are no choice.

I don't believe such an option would be very popular since one has to 
write a class for each choice and a member function for each choice arm.
It is also a partial solution that can only address some choice use-
cases, as I showed in my previous email.

Boris