[xsd-users] vocabulary-specific types for simple elements

[Boris Kolpackov]

Hi Sumant,

Sumant Tambe <sutambe at dre.vanderbilt.edu> writes:

> > No, there is no way to do this. It is also not clear what extra  
> > functionality such a class would have to justify the overhead.
>
> I see a couple of advantages of doing it.
>
> 1. The data structure representing information remains abstract behind  
> the interface of the generated class. That allows easy changes in the  
> schema without breaking (some part of) the client code. Say for  
> instance, regular strings to an enumeration of strings.

There is a typedef alias generated for each element/attribute (e.g., 
foo::price_type). If used, this will give you the same benefit without
any overhead.


> 2. The elements that logically belong to different parts of XML, can be  
> distinguished at the type level. For instance, if book titles and author  
> names, both are represented using strings, it is not clear when you see  
> a string object whether its a title or name. Some extra type-safety can  
> be achieved if they have their respective classes.

You can add syntactic clarity by using the type aliases mentioned above.
As for the extra type-safety, it is the same as in the schema. In other
words, if the author of the schema wanted to distinguish title from
author, they could have created separate types for them by deriving
from string. This would translate to separate types in C++. In fact
I've seen quite a few schemas that do this. I just don't think it is 
our place to make this decision for the user and sacrifice one thing 
for another.


> Also, other than extra classes, do you see any other overhead of such 
> an approach.

Each additional class would lead to longer compilation times, code bloat 
(each will have to have a vtable, type information, etc.). There are
schemas with thousands of types. If we were to generate a wrapper class
for each element/attribute, we could easily reach 10K classes. 

Plus, there is always the "inconvenience overhead" where the user has 
to "unwrap" things (e.g., a wrapper for type int is never as convenient 
to use as int itself).

Boris