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

[Gershanovich, Leonid]

> 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.
But once XML structure is defined and all constraints are properly described in schema would not it be natural to expect in generated code to have a similar structure?

> 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.
I do agree that in that specific case order is not important, and probably in most cases, as you pointed out, it is not important either, but I did see enough cases where order is significant.

> 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.

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, as a developer, would not expect "undefined behavior" by looking at method signature. Not at first anyway:)

Also, how choice arm is initialized in default ctor?

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

> 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.
Does this mean that "full-blown validation" in XSD/e is equivalent to Xerces validation? As right now I rely on Xerces to do validation, including xs:unique, xs:key constraints.

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


> 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.
As long as it is just one of options, developer might choose not use it and go with more straight forward way, like series if else with boost::get<T>().

But, if/when straight forward way is not good fit (consider when you actively develop schema and adding/removing elements to xs:choice) developer can always use heavier, stricter (as compiler would check that every possible choice has a handler) way with overloads.


> 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?

Leonid