From noel.farrugia at outlook.com  Thu Jul  3 10:06:20 2014
From: noel.farrugia at outlook.com (Noel Farrugia)
Date: Thu Jul  3 10:06:28 2014
Subject: [xsd-users] Skip writing the default values of attributes to the
	XML file
Message-ID: <DUB117-W12070A6D4F616A5E8FD86C2E7010@phx.gbl>

Dear Sir/Madam,
 
I am a new user to CodeSynthesis XSD and I managed to read and write to the XML file without any problems. However now I'm building an application and the XSD file has optional attributes that have a default value, for example:
 
<xs:attribute name="Age" use="optional" default="0">
 
Now I want to write to the XML file however I do not want to write attributes with default values into the file.
This can be achieved by removing the default value, for example:
 
<xs:attribute name="Age" use="optional">
 
however I cannot use this method since this will require for the modification of the XSD file and will create compatibility problems with previous versions of my application.
 
I tried to search online for a solution but to no avail.
 
Thanks a lot for your time. Hoping to hear from you soon.
 
Regards,
Noel Farrugia
 
 
 		 	   		  
From jcrq51 at hotmail.com  Thu Jul  3 16:39:29 2014
From: jcrq51 at hotmail.com (Juan Carlos Rueda Quezada)
Date: Fri Jul  4 06:03:52 2014
Subject: [xsd-users] xsd-3.3.0-gcc-4.7-clang.patch
Message-ID: <BAY175-W3617786B034AFE5C499350C1010@phx.gbl>

Hi,
I applied the patch on mac osx and my program built successfully, but i tried to do the same on Linux CentOs 6.3 without success.
When i try to build  the examples with clang++ and the option -std=c++11 , i get a lot warnings and errors:
          ^In file included from main.cpp:31:In file included from /usr/local/include/libxsd/xsd/cxx/tree/elements.hxx:20:In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/map:60:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:136:4: error: call to implicitly-deleted copy constructor of 'std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>'          _M_value_field(std::forward<_Args>(__args)...) { }          ^              ~~~~~~~~~~~~~~~~~~~~~~~~~~~/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/ext/new_allocator.h:111:23: note: in instantiation of function template specialization 'std::_Rb_tree_node<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >::_Rb_tree_node<const std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> &>' requested here        { ::new((void *)__p) _Tp(std::forward<_Args>(__args)...); }                             ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:394:32: note: in instantiation of function template specialization '__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::construct<const std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> &>' requested here              _M_get_Node_allocator().construct(__tmp,                                      ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:881:24: note: in instantiation of function template specialization 'std::_Rb_tree<const xsd::cxx::tree::identity *, std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>, std::_Select1st<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::_M_create_node<const std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> &>' requested here      _Link_type __z = _M_create_node(__v);                       ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:1215:13: note: in instantiation of member function 'std::_Rb_tree<const xsd::cxx::tree::identity *, std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>, std::_Select1st<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::_M_insert_' requested here            return _M_insert_(0, _M_rightmost(), __v);                   ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:1324:4: note: in instantiation of member function 'std::_Rb_tree<const xsd::cxx::tree::identity *, std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>, std::_Select1st<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::_M_insert_unique_' requested here          _M_insert_unique_(end(), *__first);          ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_map.h:553:16: note: in instantiation of function template specialization 'std::_Rb_tree<const xsd::cxx::tree::identity *, std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>, std::_Select1st<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::_M_insert_unique<std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >' requested here        { _M_t._M_insert_unique(__first, __last); }               ^/usr/local/include/libxsd/xsd/cxx/tree/elements.hxx:442:20: note: in instantiation of function template specialization 'std::map<const xsd::cxx::tree::identity *, xsd::cxx::tree::_type *, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::insert<std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >' requested here                m->insert (map_->begin (), map_->end ());                   ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_pair.h:92:7: note: copy constructor is implicitly deleted because 'pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>' has a user-declared move constructor      pair(pair&& __p)      ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_pair.h:89:10: error: no matching function for call to 'forward'        : first(std::forward<_U1>(__x)),                ^~~~~~~~~~~~~~~~~/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:1177:13: note: in instantiation of function template specialization 'std::pair<std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, bool>::pair<std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, bool>' requested here            return pair<iterator, bool>(_M_insert_(__x, __y, __v), true);                   ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:1217:13: note: in instantiation of member function 'std::_Rb_tree<const xsd::cxx::tree::identity *, std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>, std::_Select1st<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::_M_insert_unique' requested here            return _M_insert_unique(__v).first;                   ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:1324:4: note: in instantiation of member function 'std::_Rb_tree<const xsd::cxx::tree::identity *, std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>, std::_Select1st<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::_M_insert_unique_' requested here          _M_insert_unique_(end(), *__first);          ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_map.h:553:16: note: in instantiation of function template specialization 'std::_Rb_tree<const xsd::cxx::tree::identity *, std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *>, std::_Select1st<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::_M_insert_unique<std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >' requested here        { _M_t._M_insert_unique(__first, __last); }               ^/usr/local/include/libxsd/xsd/cxx/tree/elements.hxx:442:20: note: in instantiation of function template specialization 'std::map<const xsd::cxx::tree::identity *, xsd::cxx::tree::_type *, xsd::cxx::tree::_type::identity_comparator, std::allocator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >::insert<std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > >' requested here                m->insert (map_->begin (), map_->end ());                   ^/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/move.h:51:5: note: candidate function [with _Tp = std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >] not viable: no known conversion from 'std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> >' to 'typename std::identity<_Rb_tree_iterator<pair<const identity *const, _type *> > >::type &&' (aka 'std::_Rb_tree_iterator<std::pair<const xsd::cxx::tree::identity *const, xsd::cxx::tree::_type *> > &&') for 1st argument    forward(typename std::identity<_Tp>::type&& __t)

I am building following this steps:
1. Modify the compilers.make file
$ cd /apps/Dev/xsd-3.3.0-x86_64-linux-gnu/examples/build/cxx/
$ vi compilers.make
# file      : examples/build/cxx/compilers.make# author    : Boris Kolpackov <boris@codesynthesis.com># copyright : Copyright (c) 2006-2010 Code Synthesis Tools CC# license   : GNU GPL v2 + exceptions; see accompanying LICENSE file
CXX := clang++
3.  $ cd /apps/Dev/xsd-3.3.0-x86_64-linux-gnu/examples/cxx/tree/hello4. $ make clean5. $ make


Could you help me.
my setup is:
Operating system:CentOS 6.3Linux 2.6.32-279.el6.x86_64 x86_64


Clang compiler:
clang version 3.5.0 (trunk 212189) (llvm/trunk 212188)Target: x86_64-unknown-linux-gnuThread model: posix
GNU compiler:
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)Copyright (C) 2010 Free Software Foundation, Inc.


 		 	   		  
From boris at codesynthesis.com  Fri Jul  4 06:01:09 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jul  4 06:05:55 2014
Subject: [xsd-users] Skip writing the default values of attributes to the
	XML file
In-Reply-To: <DUB117-W12070A6D4F616A5E8FD86C2E7010@phx.gbl>
References: <DUB117-W12070A6D4F616A5E8FD86C2E7010@phx.gbl>
Message-ID: <boris.20140704120014@codesynthesis.com>

Hi Noel,

Noel Farrugia <noel.farrugia@outlook.com> writes:

> I tried to search online for a solution but to no avail.

See the --omit-default-attributes XSD compiler option. Described here:

http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml

Boris

From boris at codesynthesis.com  Fri Jul  4 06:58:39 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jul  4 07:03:26 2014
Subject: [xsd-users] xsd-3.3.0-gcc-4.7-clang.patch
In-Reply-To: <BAY175-W3617786B034AFE5C499350C1010@phx.gbl>
References: <BAY175-W3617786B034AFE5C499350C1010@phx.gbl>
Message-ID: <boris.20140704125311@codesynthesis.com>

Hi Juan,

Juan Carlos Rueda Quezada <jcrq51@hotmail.com> writes:

> When i try to build  the examples with clang++ and the option -std=c++11, 
> i get a lot warnings and errors:

All the diagnostics points to the STL implementation that comes from GCC
4.4. I doubt it very much it can be compiled in the C++11 mode. Are you
able to build any other code that uses STL in this mode?

Even if you resolve these, you will still get some warnings from XSD
code when compiling as C++11 (std::auto_ptr will probably be the most
common one). To resolve these the best option is probably to upgrade
to the pre-release which has support for C++11 (the --std c++11 option).
I am in the final stages of preparing for the release. You can either
wait a week or two or I can build you a beta.

Boris

From jcrq51 at hotmail.com  Fri Jul  4 07:43:20 2014
From: jcrq51 at hotmail.com (Juan Carlos Rueda Quezada)
Date: Fri Jul  4 07:45:51 2014
Subject: [xsd-users] xsd-3.3.0-gcc-4.7-clang.patch
Message-ID: <BAY404-EAS6557E57821AD65C5D1DF82C1000@phx.gbl>

Hi Boris

Thaks for your answer. Currently my program compiles ok on mac osx with clang and -std=c++11 but the final deployment is on centOs. Why the patch don't have the same effect on centos with clang++.

Another question, the code that a have writen with the current release would be compatible with the next release?.

Thanks in advance.


Enviado desde Samsung Mobile

<div>-------- Mensaje original --------</div><div>De: Boris Kolpackov <boris@codesynthesis.com> </div><div>Fecha:04/07/2014  06:03 AM  (GMT-05:00) </div><div>A: Juan Carlos Rueda Quezada <jcrq51@hotmail.com> </div><div>CC: xsd-users@codesynthesis.com </div><div>Asunto: Re: [xsd-users] xsd-3.3.0-gcc-4.7-clang.patch </div><div>
</div>
Hi Juan,

Juan Carlos Rueda Quezada <jcrq51@hotmail.com> writes:

> When i try to build  the examples with clang++ and the option -std=c++11,
> i get a lot warnings and errors:

All the diagnostics points to the STL implementation that comes from GCC
4.4. I doubt it very much it can be compiled in the C++11 mode. Are you
able to build any other code that uses STL in this mode?

Even if you resolve these, you will still get some warnings from XSD
code when compiling as C++11 (std::auto_ptr will probably be the most
common one). To resolve these the best option is probably to upgrade
to the pre-release which has support for C++11 (the --std c++11 option).
I am in the final stages of preparing for the release. You can either
wait a week or two or I can build you a beta.

Boris
From boris at codesynthesis.com  Fri Jul  4 07:55:29 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jul  4 08:00:16 2014
Subject: [xsd-users] xsd-3.3.0-gcc-4.7-clang.patch
In-Reply-To: <BAY404-EAS6557E57821AD65C5D1DF82C1000@phx.gbl>
References: <BAY404-EAS6557E57821AD65C5D1DF82C1000@phx.gbl>
Message-ID: <boris.20140704135210@codesynthesis.com>

Hi Juan,

Juan Carlos Rueda Quezada <jcrq51@hotmail.com> writes:

> Currently my program compiles ok on mac osx with clang and -std=c++11
> but the final deployment is on centOs. Why the patch don't have the
> same effect on centos with clang++.

It is not the patch or your code, it is your toolchain on CentOS
that's the problem. Using GCC 4.4 runtime in C++11 model is most
likely not going to work.


> Another question, the code that a have writen with the current
> release would be compatible with the next release?.

There aren't many breaking changes, so, yes, everything should
work with minimal modifications (e.g., change auto_ptr to
unique_ptr if using the C++11 mode).

Boris

From jcrq51 at hotmail.com  Fri Jul  4 09:56:40 2014
From: jcrq51 at hotmail.com (Juan Carlos Rueda Quezada)
Date: Fri Jul  4 10:31:48 2014
Subject: [xsd-users] xsd-3.3.0-gcc-4.7-clang.patch
Message-ID: <BAY404-EAS37629E8265B85C1903362CBC1000@phx.gbl>

Hi Boris

I built successfully my program using g++ 4.7 -std=c++0?
Thank you so much :)


Enviado desde Samsung Mobile

<div>-------- Mensaje original --------</div><div>De: Boris Kolpackov <boris@codesynthesis.com> </div><div>Fecha:04/07/2014  07:00 AM  (GMT-05:00) </div><div>A: Juan Carlos Rueda Quezada <jcrq51@hotmail.com> </div><div>CC: xsd-users@codesynthesis.com </div><div>Asunto: Re: [xsd-users] xsd-3.3.0-gcc-4.7-clang.patch </div><div>
</div>
Hi Juan,

Juan Carlos Rueda Quezada <jcrq51@hotmail.com> writes:

> Currently my program compiles ok on mac osx with clang and -std=c++11
> but the final deployment is on centOs. Why the patch don't have the
> same effect on centos with clang++.

It is not the patch or your code, it is your toolchain on CentOS
that's the problem. Using GCC 4.4 runtime in C++11 model is most
likely not going to work.


> Another question, the code that a have writen with the current
> release would be compatible with the next release?.

There aren't many breaking changes, so, yes, everything should
work with minimal modifications (e.g., change auto_ptr to
unique_ptr if using the C++11 mode).

Boris
From tolgatuna_09 at hotmail.com  Mon Jul  7 03:02:05 2014
From: tolgatuna_09 at hotmail.com (Tolga TUNA)
Date: Mon Jul  7 03:02:14 2014
Subject: [xsd-users] xml_schema exceptions
Message-ID: <DUB114-W96EA4BEBC15434E22A3049E60D0@phx.gbl>

Hi,
Is it possible to convert that exception to standart string?
    } catch (const xml_schema::exception& e) {
        std::cerr << e << std::endl;        // e.c_str(); -> like this?
    }

--
Tolga TUNASistem M?hendisiBilgi Sistem M?hendisli?iEntegre ?r?n Programlar?Savunma ve ?r?n Grubu
CepNo  :  0536 599 45 38E-mail  :  tolgatuna_09@hotmail.com
                tolga.tuna@savronik.com.tr 		 	   		  
From boris at codesynthesis.com  Mon Jul  7 04:35:07 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jul  7 04:39:54 2014
Subject: [xsd-users] xml_schema exceptions
In-Reply-To: <DUB114-W96EA4BEBC15434E22A3049E60D0@phx.gbl>
References: <DUB114-W96EA4BEBC15434E22A3049E60D0@phx.gbl>
Message-ID: <boris.20140707103343@codesynthesis.com>

Hi Tolga,

Tolga TUNA <tolgatuna_09@hotmail.com> writes:

> Is it possible to convert that exception to standart string?
>     } catch (const xml_schema::exception& e) {
>         std::cerr << e << std::endl;        // e.c_str(); -> like this?
>     }

#include <sstream>

std::ostringstream os;
os << e;
std::string s (e.str ());

Boris

From rlischner at proteuseng.com  Fri Jul 18 11:03:03 2014
From: rlischner at proteuseng.com (Ray Lischner)
Date: Mon Jul 21 04:22:29 2014
Subject: [xsd-users] deque instead of vector
Message-ID: <68F9DD51BF61E943BFA45D744048A7A731A49A674F@nbp-ex01.proteus-technologies.com>

We have a use case for wanting to use a deque instead of a vector for an element with cardinality > 1. I've been trying to think of an easy way to do this, but I haven't thought of one yet. Any recommendations?

Ray Lischner,
Distinguished Member of Technical Staff
133 National Business Pkwy, Ste 150     t. 443.539.3448
Annapolis Junction, MD 20701            c. 301.377.7668
rlischner@proteuseng.com                f. 443.539.3370
From boris at codesynthesis.com  Mon Jul 21 05:26:29 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jul 21 05:31:34 2014
Subject: [xsd-users] deque instead of vector
In-Reply-To: <68F9DD51BF61E943BFA45D744048A7A731A49A674F@nbp-ex01.proteus-technologies.com>
References: <68F9DD51BF61E943BFA45D744048A7A731A49A674F@nbp-ex01.proteus-technologies.com>
Message-ID: <boris.20140721112522@codesynthesis.com>

Hi Ray,

Ray Lischner <rlischner@proteuseng.com> writes:

> We have a use case for wanting to use a deque instead of a vector
> for an element with cardinality > 1.

If it is in a single types (or a handful of types), then type
customization is probably the most straightforward way.

Boris

From boris at codesynthesis.com  Tue Jul 22 05:23:40 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Jul 22 05:28:46 2014
Subject: [xsd-users] XSD 4.0.0 released
Message-ID: <boris.20140722112217@codesynthesis.com>

Hi,

We have released XSD 4.0.0. The NEWS file entries for this release are
as follows:

  * Xerces-C++ 2-series (2.8.0 and earlier) is no longer supported.

  * Visual Studio 2003 (7.1) is no longer supported.

  * HP aCC3 (HP-UX/PA-RISC) is no longer supported.

  * Oracle/Berkeley DB XML support has been removed since it no longer
    supports the Xerces-C++-based document access.

  * New option, --std, specifies the C++ standard that the generated code
    should conform to. Valid values are c++98 (default) and c++11.

    The C++ standard affects various aspects of the generated code that are
    discussed in more detail in mapping-specific documentation (guides and
    manuals). Overall, when C++11 is selected, the generated code relies on
    the move semantics and uses std::unique_ptr instead of deprecated
    std::auto_ptr. See also the documentation for the --std option in the
    XSD compiler command line manual (man pages).

  * New option, --fat-type-file, triggers the placement of code corresponding
    to global elements into type files instead of schema files in the file-
    per-type mode. This option is primarily useful when trying to minimize
    the amount of object code that is linked to an executable by packaging
    compiled generated code into a static (archive) library.

C++/Tree

  * Support for ordered types. C++/Tree flattens nested compositors which
    sometimes can result in the loss of element ordering information that
    could be significant to the application. Ordered types address this
    problem. For more information, refer to Section 2.8.4, "Element Order"
    in the C++/Tree Mapping User Manual.

  * Support for mixed content in ordered types. For more information, refer
    to Section 2.13, "Mapping for Mixed Content Models" in the C++/Tree
    Mapping User Manual.

  * xml_schema::type represents anyType content as a DOM fragment, similar
    to wildcards. For more information, refer to Section 2.5.2, "Mapping
    for anyType" in the C++/Tree Mapping User Manual.

  * xml_schema::simple_type represents anySimpleType content as a text
    string. For more information, refer to Section 2.5.3, "Mapping for
    anySimpleType" in the C++/Tree Mapping User Manual.

  * Improved streaming example that now provides better XML namespace
    handling and supports streaming parsing and serialization at multiple
    document levels.

  * New option, --generate-dep, triggers the generation of the make
    dependency files (.d) for the generated C++ files. Other options
    controlling dependency generation are: --generate-dep-only,
    --dep-phony, --dep-target, --dep-suffix, and --dep-regex. For
    details on this functionality, refer to the XSD compiler command
    line manual (man pages).

  * New option, --suppress-assignment, suppresses the generation of copy
    assignment operators for complex types. If this option is specified,
    the copy assignment operators for such types are declared private and
    left unimplemented.

  * Binary representation now stores string-based enumerations as integer
    values corresponding to C++ enumerators instead of string literals.

  * Binary representation now pools polymorphic type-id strings in an
    implicit string pool. The string pool support can also be used to
    pool strings in other situations. For example, you can implement
    string insertion/extraction operators for your stream to pool all
    strings. This can be useful if your documents contain a large number
    of repetitive strings.

  * New option, --polymorphic-plate, allows the creation of multiple
    polymorphic map plates in the same application. For details, refer
    to the XSD compiler command line manual (man pages).

  * To get the DOM association in the copy of an object model tree one
    now needs to explicitly pass the xml_schema::flags::keep_dom flag as
    the second argument to the copy constructor or clone() function.

This release also adds support for Clang as well as Visual Studio 2012
(11.0) and 2013 (12.0), including project/solution files for all the
examples. The .msi package also includes pre-built Xerces-C++ libraries
for these versions of VC++.

A more detailed discussion of the major new features can be found in the
following blog post:

http://www.codesynthesis.com/~boris/blog/2014/07/22/codesynthesis-xsd-4-0-0-released/

We would also like to thank everyone who reported bugs, suggested fixes
or new features, as well as tested early versions of this release.

Source code and pre-compiled binary packages for this release are available
from the XSD Download page:

http://www.codesynthesis.com/products/xsd/download.xhtml

SHA1 checksums for the files in this release are as follows:

4b4670f60ce2009d8a2c5ece9b93e88c4bd5de8a  xsd-4.0.0-1.i686.rpm
bf79548c8030dbd5489a54ac5c5d543e1a35bb73  xsd_4.0.0-1_i386.deb
6d244d447cc995cc7df77dcf0f015d60002782a0  xsd-4.0.0-i686-linux-gnu.tar.bz2
47b8b65c7f68d34848e3226aaddb4352a37ca375  xsd-4.0.0-1.x86_64.rpm
4f5030518ec7691ca5517ac06f0905d0ee06699b  xsd_4.0.0-1_amd64.deb
bb96454da6acafb93180368220d555e2b9747023  xsd-4.0.0-i686-macosx.tar.bz2
5eeb2eeca0d893949e3677bb374e7b96f19770d6  xsd-4.0.0-x86_64-linux-gnu.tar.bz2
d92124e9ac50ced783184469059e88c96481a683  xsd-4.0.0-i686-solaris.tar.bz2
c830b060f7003937cb7b88231614b118832554e9  xsd-4.0.0-sparc-solaris.tar.bz2
d129469e109784c663387ca8bee5ac627434cfca  xsd-4.0.0-i686-windows.zip
3a6ea8b4475c7bc4376c0e7058b6cf87473dce1f  xsd-4.0.msi
7e2a3924c3cee4ab839b9c2a6369464caacd2ef5  xsd-4.0.0.tar.bz2
ad3de699eb140e747a0a214462d95fc81a21b494  xsd-4.0.0+dep.tar.bz2

Enjoy,
	Boris

From mjklaim at gmail.com  Tue Jul 22 12:54:41 2014
From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=)
Date: Tue Jul 22 12:54:48 2014
Subject: [xsd-users] XSD 4.0.0 released
In-Reply-To: <boris.20140722112217@codesynthesis.com>
References: <boris.20140722112217@codesynthesis.com>
Message-ID: <CAOU91OPPXP1dghM0fNtb4bQO-569ApGNce0=Eec_395KFHax-w@mail.gmail.com>

?Congratulations for this release!
I will be happy to test it when I get back to my project using xsd.
The main issues I had with xsd seems to have a solution now.

I have some issues with xerces not being easy to build though, and I don't
like to push binaries of xerces in my dependencies repository, but oh well.

I'll report any problem.
From boris at codesynthesis.com  Wed Jul 23 03:04:38 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jul 23 03:09:43 2014
Subject: [xsd-users] XSD 4.0.0 released
In-Reply-To: <CAOU91OPPXP1dghM0fNtb4bQO-569ApGNce0=Eec_395KFHax-w@mail.gmail.com>
References: <boris.20140722112217@codesynthesis.com>
	<CAOU91OPPXP1dghM0fNtb4bQO-569ApGNce0=Eec_395KFHax-w@mail.gmail.com>
Message-ID: <boris.20140723090302@codesynthesis.com>

Hi Jo?l,

Klaim - Jo?l Lamotte <mjklaim@gmail.com> writes:

> Congratulations for this release!

Thanks!


> I have some issues with xerces not being easy to build though

What exactly is not easy? It uses standard ./configure && make
on UNIX-likes platforms and comes with VC++ project/solution
files for Windows.

Boris

From mjklaim at gmail.com  Wed Jul 23 03:58:11 2014
From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=)
Date: Wed Jul 23 03:58:18 2014
Subject: [xsd-users] XSD 4.0.0 released
In-Reply-To: <boris.20140723090302@codesynthesis.com>
References: <boris.20140722112217@codesynthesis.com>
	<CAOU91OPPXP1dghM0fNtb4bQO-569ApGNce0=Eec_395KFHax-w@mail.gmail.com>
	<boris.20140723090302@codesynthesis.com>
Message-ID: <CAOU91OMUz6JzrDjWfaG0Fhc2OOHXn+YmbuAbdzh72JLMuBKxKg@mail.gmail.com>

On Wed, Jul 23, 2014 at 9:04 AM, Boris Kolpackov <boris@codesynthesis.com>
wrote:

> What exactly is not easy? It uses standard ./configure && make
> on UNIX-likes platforms and comes with VC++ project/solution
> files for Windows.
>

I use cmake but I'm not an expert so it might be my lack of understanding.
I wanted (some time ago) to put a version of xsd sources into this
repository (dependencies for my project):
https://github.com/artofsequence/aos-cpp-dependencies
But when I tried I realized that I would have to add xerces too, at which
point I looked at Xerces sources but didn't understand everything at the
time.
I'll try again soon anyway.
From om_codesynthesis at keywallet.com  Wed Jul 23 20:29:57 2014
From: om_codesynthesis at keywallet.com (Ovanes Markarian)
Date: Wed Jul 23 20:30:27 2014
Subject: [xsd-users] expat build fails with 4.0
Message-ID: <CAH_e8=sCe_Cu5+K0s_9ZzLWXkBXiX01mEuhKqf2=KayvcEY4-g@mail.gmail.com>

Hello *,

there seems to be a minor misconception with expat interface. Clang 3.4 on
Mac OS X gives me the error:

/usr/local/include/xsd/cxx/parser/expat/elements.txx:313:17: error: no
matching function for call to 'XML_Parse'
            if (XML_Parse (
                ^~~~~~~~~
/usr/local/include/expat.h:778:1: note: candidate function not viable: no
known conversion from 'parser_auto_ptr' (aka
'unique_ptr<XML_ParserStruct>') to 'XML_Parser' (aka 'XML_ParserStruct *')
for 1st argument
XML_Parse(XML_Parser parser, const char *s, int len, int isFinal);
^

std::unique_ptr does not implicitly converts to the pointer to the value
contained there...

IMO there must be:

            if (XML_Parse (
                  parser.get(), buf, is.gcount (), is.eof ()) ==
XML_STATUS_ERROR)
                           ^^^^^
           {
              r = false;
              break;
            }

which fixes the problem. But I'am not sure weather I'am correct about
passing a bare pointer. I think yes, as expat is a C based parser.


Thanks for the new release,
Ovanes
From om_codesynthesis at keywallet.com  Wed Jul 23 21:01:12 2014
From: om_codesynthesis at keywallet.com (Ovanes Markarian)
Date: Wed Jul 23 21:01:40 2014
Subject: [xsd-users] Re: expat build fails with 4.0
In-Reply-To: <CAH_e8=sCe_Cu5+K0s_9ZzLWXkBXiX01mEuhKqf2=KayvcEY4-g@mail.gmail.com>
References: <CAH_e8=sCe_Cu5+K0s_9ZzLWXkBXiX01mEuhKqf2=KayvcEY4-g@mail.gmail.com>
Message-ID: <CAH_e8=sDn_9DdMA-4JNjnSSmxRPez15SNaAPUZcqJUhgn3sBhw@mail.gmail.com>

I get even more errors :(


Seems like the in the expat version which I have installed (2.1.0)
XML_ParserStruct is an incomplete type. I can't find the definition of the
struct in any of the header files. Therefore it is an incomplete type and
unique_ptr implementation can't delete it. Luckily there was a
static_assert :)


In file included from /usr/local/include/xsd/cxx/xml/error-handler.hxx:8:
In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/string:439:
In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:627:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:2424:27:
error: invalid application of 'sizeof' to an incomplete type
'XML_ParserStruct'
            static_assert(sizeof(_Tp) > 0, "default_delete can not delete
incomplete type");
                          ^~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:2625:13:
note: in instantiation of member function
'std::__1::default_delete<XML_ParserStruct>::operator()' requested here
            __ptr_.second()(__tmp);
            ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:2593:46:
note: in instantiation of member function
'std::__1::unique_ptr<XML_ParserStruct,
std::__1::default_delete<XML_ParserStruct> >::reset' requested here
    _LIBCPP_INLINE_VISIBILITY ~unique_ptr() {reset();}
                                             ^
/usr/local/include/xsd/cxx/parser/expat/elements.hxx:102:16: note: in
instantiation of member function 'std::__1::unique_ptr<XML_ParserStruct,
std::__1::default_delete<XML_ParserStruct> >::~unique_ptr' requested here
        struct document: cxx::parser::document<C> // VC likes it qualified
               ^
/usr/local/include/expat.h:24:8: note: forward declaration of
'XML_ParserStruct'
struct XML_ParserStruct;
       ^


On Thu, Jul 24, 2014 at 2:29 AM, Ovanes Markarian <
om_codesynthesis@keywallet.com> wrote:

> Hello *,
>
> there seems to be a minor misconception with expat interface. Clang 3.4 on
> Mac OS X gives me the error:
>
> /usr/local/include/xsd/cxx/parser/expat/elements.txx:313:17: error: no
> matching function for call to 'XML_Parse'
>             if (XML_Parse (
>                 ^~~~~~~~~
> /usr/local/include/expat.h:778:1: note: candidate function not viable: no
> known conversion from 'parser_auto_ptr' (aka
> 'unique_ptr<XML_ParserStruct>') to 'XML_Parser' (aka 'XML_ParserStruct *')
> for 1st argument
> XML_Parse(XML_Parser parser, const char *s, int len, int isFinal);
> ^
>
> std::unique_ptr does not implicitly converts to the pointer to the value
> contained there...
>
> IMO there must be:
>
>             if (XML_Parse (
>                   parser.get(), buf, is.gcount (), is.eof ()) ==
> XML_STATUS_ERROR)
>                            ^^^^^
>            {
>               r = false;
>               break;
>             }
>
> which fixes the problem. But I'am not sure weather I'am correct about
> passing a bare pointer. I think yes, as expat is a C based parser.
>
>
> Thanks for the new release,
> Ovanes
>
From om_codesynthesis at keywallet.com  Wed Jul 23 21:36:01 2014
From: om_codesynthesis at keywallet.com (Ovanes Markarian)
Date: Wed Jul 23 21:36:30 2014
Subject: [xsd-users] Re: expat build fails with 4.0
In-Reply-To: <CAH_e8=sDn_9DdMA-4JNjnSSmxRPez15SNaAPUZcqJUhgn3sBhw@mail.gmail.com>
References: <CAH_e8=sCe_Cu5+K0s_9ZzLWXkBXiX01mEuhKqf2=KayvcEY4-g@mail.gmail.com>
	<CAH_e8=sDn_9DdMA-4JNjnSSmxRPez15SNaAPUZcqJUhgn3sBhw@mail.gmail.com>
Message-ID: <CAH_e8=vas94D-ikJHbu_EL-md9ekB+5Trv0H_U8J1D_HvOcUuw@mail.gmail.com>

OK, after patching some files got it working :(

Here are the patches:

elements.hxx, line: 54

change typedef to:
       typedef std::unique_ptr<XML_ParserStruct, parser_deleter>
parser_auto_ptr;

There was no parser deleter specification

elements.txx:

Had in two places:
  begin_parse(parser, ...) calls and these must be:
  begin_parse(parser.get(), ...) calls.


Would be great if you could verify these proposals and release a new
version.


On Thu, Jul 24, 2014 at 3:01 AM, Ovanes Markarian <
om_codesynthesis@keywallet.com> wrote:

> I get even more errors :(
>
>
> Seems like the in the expat version which I have installed (2.1.0)
> XML_ParserStruct is an incomplete type. I can't find the definition of the
> struct in any of the header files. Therefore it is an incomplete type and
> unique_ptr implementation can't delete it. Luckily there was a
> static_assert :)
>
>
> In file included from /usr/local/include/xsd/cxx/xml/error-handler.hxx:8:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/string:439:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:627:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:2424:27:
> error: invalid application of 'sizeof' to an incomplete type
> 'XML_ParserStruct'
>             static_assert(sizeof(_Tp) > 0, "default_delete can not delete
> incomplete type");
>                           ^~~~~~~~~~~
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:2625:13:
> note: in instantiation of member function
> 'std::__1::default_delete<XML_ParserStruct>::operator()' requested here
>             __ptr_.second()(__tmp);
>             ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:2593:46:
> note: in instantiation of member function
> 'std::__1::unique_ptr<XML_ParserStruct,
> std::__1::default_delete<XML_ParserStruct> >::reset' requested here
>     _LIBCPP_INLINE_VISIBILITY ~unique_ptr() {reset();}
>                                              ^
> /usr/local/include/xsd/cxx/parser/expat/elements.hxx:102:16: note: in
> instantiation of member function 'std::__1::unique_ptr<XML_ParserStruct,
> std::__1::default_delete<XML_ParserStruct> >::~unique_ptr' requested here
>         struct document: cxx::parser::document<C> // VC likes it qualified
>                ^
> /usr/local/include/expat.h:24:8: note: forward declaration of
> 'XML_ParserStruct'
> struct XML_ParserStruct;
>        ^
>
>
> On Thu, Jul 24, 2014 at 2:29 AM, Ovanes Markarian <
> om_codesynthesis@keywallet.com> wrote:
>
>> Hello *,
>>
>> there seems to be a minor misconception with expat interface. Clang 3.4
>> on Mac OS X gives me the error:
>>
>> /usr/local/include/xsd/cxx/parser/expat/elements.txx:313:17: error: no
>> matching function for call to 'XML_Parse'
>>             if (XML_Parse (
>>                 ^~~~~~~~~
>> /usr/local/include/expat.h:778:1: note: candidate function not viable: no
>> known conversion from 'parser_auto_ptr' (aka
>> 'unique_ptr<XML_ParserStruct>') to 'XML_Parser' (aka 'XML_ParserStruct *')
>> for 1st argument
>> XML_Parse(XML_Parser parser, const char *s, int len, int isFinal);
>> ^
>>
>> std::unique_ptr does not implicitly converts to the pointer to the value
>> contained there...
>>
>> IMO there must be:
>>
>>             if (XML_Parse (
>>                   parser.get(), buf, is.gcount (), is.eof ()) ==
>> XML_STATUS_ERROR)
>>                            ^^^^^
>>            {
>>               r = false;
>>               break;
>>             }
>>
>> which fixes the problem. But I'am not sure weather I'am correct about
>> passing a bare pointer. I think yes, as expat is a C based parser.
>>
>>
>> Thanks for the new release,
>> Ovanes
>>
>
>
From boris at codesynthesis.com  Thu Jul 24 06:42:54 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jul 24 06:48:00 2014
Subject: [xsd-users] Re: expat build fails with 4.0
In-Reply-To: <CAH_e8=vas94D-ikJHbu_EL-md9ekB+5Trv0H_U8J1D_HvOcUuw@mail.gmail.com>
References: <CAH_e8=sCe_Cu5+K0s_9ZzLWXkBXiX01mEuhKqf2=KayvcEY4-g@mail.gmail.com>
	<CAH_e8=sDn_9DdMA-4JNjnSSmxRPez15SNaAPUZcqJUhgn3sBhw@mail.gmail.com>
	<CAH_e8=vas94D-ikJHbu_EL-md9ekB+5Trv0H_U8J1D_HvOcUuw@mail.gmail.com>
Message-ID: <boris.20140724124034@codesynthesis.com>

Hi Ovanes,

Ovanes Markarian <om_codesynthesis@keywallet.com> writes:

> Would be great if you could verify these proposals 

Yes, the fixes are correct, thanks! I have applied them for the next
release.


> ... and release a new version.

Since the changes are only to the header-only libxsd, it is a matter
of simply applying the patch:

http://scm.codesynthesis.com/?p=xsd/xsd.git;a=commit;h=94cba986108a0e0f42295572ca42c356d59328d7

Boris

From om_codesynthesis at keywallet.com  Thu Jul 24 14:57:12 2014
From: om_codesynthesis at keywallet.com (Ovanes Markarian)
Date: Thu Jul 24 14:57:40 2014
Subject: [xsd-users] Re: expat build fails with 4.0
In-Reply-To: <boris.20140724124034@codesynthesis.com>
References: <CAH_e8=sCe_Cu5+K0s_9ZzLWXkBXiX01mEuhKqf2=KayvcEY4-g@mail.gmail.com>
	<CAH_e8=sDn_9DdMA-4JNjnSSmxRPez15SNaAPUZcqJUhgn3sBhw@mail.gmail.com>
	<CAH_e8=vas94D-ikJHbu_EL-md9ekB+5Trv0H_U8J1D_HvOcUuw@mail.gmail.com>
	<boris.20140724124034@codesynthesis.com>
Message-ID: <CAH_e8=vv1c6RJ5RGVGhEAwjsp+sJfLO8uzUOcs-D3rk4nfpdeA@mail.gmail.com>

I think a 4.0.1 release would make things easier, just download and go on
instead of additional step: patching the stuff.


On Thu, Jul 24, 2014 at 12:42 PM, Boris Kolpackov <boris@codesynthesis.com>
wrote:

> Hi Ovanes,
>
> Ovanes Markarian <om_codesynthesis@keywallet.com> writes:
>
> > Would be great if you could verify these proposals
>
> Yes, the fixes are correct, thanks! I have applied them for the next
> release.
>
>
> > ... and release a new version.
>
> Since the changes are only to the header-only libxsd, it is a matter
> of simply applying the patch:
>
>
> http://scm.codesynthesis.com/?p=xsd/xsd.git;a=commit;h=94cba986108a0e0f42295572ca42c356d59328d7
>
> Boris
>
>
From boris at codesynthesis.com  Fri Jul 25 02:27:52 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jul 25 02:32:57 2014
Subject: [xsd-users] Re: expat build fails with 4.0
In-Reply-To: <CAH_e8=vv1c6RJ5RGVGhEAwjsp+sJfLO8uzUOcs-D3rk4nfpdeA@mail.gmail.com>
References: <CAH_e8=sCe_Cu5+K0s_9ZzLWXkBXiX01mEuhKqf2=KayvcEY4-g@mail.gmail.com>
	<CAH_e8=sDn_9DdMA-4JNjnSSmxRPez15SNaAPUZcqJUhgn3sBhw@mail.gmail.com>
	<CAH_e8=vas94D-ikJHbu_EL-md9ekB+5Trv0H_U8J1D_HvOcUuw@mail.gmail.com>
	<boris.20140724124034@codesynthesis.com>
	<CAH_e8=vv1c6RJ5RGVGhEAwjsp+sJfLO8uzUOcs-D3rk4nfpdeA@mail.gmail.com>
Message-ID: <boris.20140725082459@codesynthesis.com>

Hi Ovanes,

Ovanes Markarian <om_codesynthesis@keywallet.com> writes:

> I think a 4.0.1 release would make things easier, just download and go on
> instead of additional step: patching the stuff.

Yes, it would definitely be easier on your side. However, releasing
a new version of XSD is a very time-consuming process that involves
a lot of testing, packaging, binary building, etc. Doing all this
for every relatively minor bug wouldn't leave us much time for any
new development.

Boris

From mirhadi at gmail.com  Mon Jul 28 02:20:03 2014
From: mirhadi at gmail.com (Hooman Mirhadi)
Date: Mon Jul 28 02:20:10 2014
Subject: [xsd-users] unsuccessful parse of Siri protocol on linux(x86) with
	g++
Message-ID: <CAP4FVKkw+Z1uF8=35aZgmxvJ=SYmPa6jSB=wv-LJHfLHA+WbkA@mail.gmail.com>

I used xsdSynthesis to compile the Siri protocol. The schema is
downloadable from:
http://user47094.vs.easily.co.uk/siri/schema/2.0/Siri_XML-v2.0.zip

I compiled the schema into an static library using this command:
*xsd cxx-tree --generate-serialization --type-naming ucc --function-naming
lcc --file-per-type --root-element-all --output-dir $(XSD_OUT) \*
*--generate-polymorphic \*
*--polymorphic-type ErrorCodeStructure \*
*--polymorphic-type AbstractRequestStructure  \*
*--polymorphic-type AbstractServiceRequestStructure \*
*--polymorphic-type ResponseStructure \*
*--polymorphic-type AuthenticatedRequestStructure \*
*--polymorphic-type ProducerRequestEndpointStructure \*
*--polymorphic-type RequestStructure \*
*--polymorphic-type AbstractFunctionalServiceRequestStructure \*
*--polymorphic-type AbstractSubscriptionStructure \*
*--polymorphic-type AbstractServiceDeliveryStructure \*
*--polymorphic-type AbstractServiceCapabilitiesResponseStructure \*
*--polymorphic-type AbstractFeederItemStructure \*
*--polymorphic-type AbstractDiscoveryRequestStructure \*
*--polymorphic-type AbstractDiscoveryDeliveryStructure \*
*--namespace-map http://datex2.eu/schema/2_0RC1/2_0=datex2
<http://datex2.eu/schema/2_0RC1/2_0=datex2> \*
*../common/xsd/siri.xsd*
*g++ -W -Wall -O3 -c `ls $(XSD_OUT)/*.cxx`*
*ar rvs $(XSD_OUT)/libxsd.a `ls -1 $(XSD_OUT) | grep .cxx | sed
s/.cxx/.o/g`*

then I used a simple piece of code to test it.

*EH eh;*
*ostringstream os;*
*xml_schema::DateTime dt(2012,6,15,12,46,5,4,0);*
*siri::ParticipantRefStructure ref("305453");*
*ServiceRequest x(dt, ref);*
*serviceRequest((ostream &)os, x, eh);*
*DEBUG(1, "ServiceRequest made: \n%s\n", os.str().c_str());*

*istringstream is(os.str().c_str());*
*try*
*{*
*auto_ptr<ServiceRequest> sr ( serviceRequest(is, eh) );*
*}*
*catch(xsd::cxx::tree::parsing<char> err)*
*{*
*DEBUG(0, "exception(xsd::cxx::tree::parsing<char>):\n%s", err.what());*
*}*

The output:

*ServiceRequest made:*
*<?xml version="1.0" encoding="UTF-8" standalone="no" ?>*
*<p1:ServiceRequest xmlns:p1="http://www.siri.org.uk/siri
<http://www.siri.org.uk/siri>">*

*  <p1:RequestTimestamp>2012-06-15T12:46:05+04:00</p1:RequestTimestamp>*

*  <p1:RequestorRef>305453</p1:RequestorRef>*

*</p1:ServiceRequest>*


*exception: >< 2 59 >no declaration found for element 'p1:ServiceRequest'<*
*exception: >< 2 59 >attribute '{http://www.w3.org/2000/xmlns/}p1
<http://www.w3.org/2000/xmlns/}p1>' is not declared for element
'p1:ServiceRequest'<*
*exception: >< 4 24 >no declaration found for element
'p1:RequestTimestamp'<*
*exception: >< 6 20 >no declaration found for element 'p1:RequestorRef'<*
*exception(xsd::cxx::tree::parsing<char>):*
*instance document parsing failed*



I expected the code to parse whatever it has serialised itself. But
unfortunately it doesn't:(
Can you help me?
From xsd-users at oli-obk.de  Mon Jul 28 04:49:04 2014
From: xsd-users at oli-obk.de (Oliver Schneider)
Date: Mon Jul 28 04:49:07 2014
Subject: [xsd-users] =?utf-8?q?no_abstract_base_classes_with_=22Customizi?=
 =?utf-8?q?ng_the_generated_type_=E2=80=94_the_complex_case=22?=
Message-ID: <53D60E80.5050409@oli-obk.de>

Hi,

I followed the instructions at
http://wiki.codesynthesis.com/Tree/Customization_guide#Customizing_the_generated_type_.E2.80.94_the_complex_case

The only change is that i made person_impl abstract (in xsd and
"people-custom.hxx") by declaring

virtual void print (std::ostream&) const = 0;

This caused the compilation to fail, since the _clone function of
superman_base will have the following content:

return new class superman_base (*this, f, c);

which can never, and should never be called, since no superman_base
instances should exist.

It would be great if true abstract base classes were possible in the future.

Greetings

Oliver Schneider

From boris at codesynthesis.com  Mon Jul 28 07:08:06 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jul 28 07:13:11 2014
Subject: [xsd-users] unsuccessful parse of Siri protocol on linux(x86)
	with g++
In-Reply-To: <CAP4FVKkw+Z1uF8=35aZgmxvJ=SYmPa6jSB=wv-LJHfLHA+WbkA@mail.gmail.com>
References: <CAP4FVKkw+Z1uF8=35aZgmxvJ=SYmPa6jSB=wv-LJHfLHA+WbkA@mail.gmail.com>
Message-ID: <boris.20140728130717@codesynthesis.com>

Hi Hooman,

Hooman Mirhadi <mirhadi@gmail.com> writes:

> *exception: >< 2 59 >no declaration found for element 'p1:ServiceRequest'<*

FAQ 2.1

http://wiki.codesynthesis.com/Tree/FAQ

Boris

From boris at codesynthesis.com  Mon Jul 28 07:10:04 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jul 28 07:15:09 2014
Subject: [xsd-users] no abstract =?utf-8?Q?base?=
	=?utf-8?Q?_classes_with_=22Customizing_the_generated_type_?=
	=?utf-8?B?4oCU?= the complex case"
In-Reply-To: <53D60E80.5050409@oli-obk.de>
References: <53D60E80.5050409@oli-obk.de>
Message-ID: <boris.20140728130918@codesynthesis.com>

Hi Oliver,

Oliver Schneider <xsd-users@oli-obk.de> writes:

> This caused the compilation to fail, since the _clone function of
> superman_base will have the following content:
> 
> return new class superman_base (*this, f, c);
> 
> which can never, and should never be called, since no superman_base
> instances should exist.

Then why not make _clone() pure virtual as well?

Boris

From xsd-users at oli-obk.de  Mon Jul 28 07:51:32 2014
From: xsd-users at oli-obk.de (Oliver Schneider)
Date: Mon Jul 28 07:51:35 2014
Subject: =?windows-1252?Q?Re=3A_=5Bxsd-users=5D_no_abstract_base_?=
	=?windows-1252?Q?classes_with_=22Customizing_the_generated_typ?=
	=?windows-1252?Q?e_=97_the_complex_case=22?=
In-Reply-To: <boris.20140728130918@codesynthesis.com>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
Message-ID: <53D63944.7050903@oli-obk.de>

Hi Boris,

Am 28.07.2014 13:10, schrieb Boris Kolpackov:
>> This caused the compilation to fail, since the _clone function of
>> superman_base will have the following content:
>>
>> return new class superman_base (*this, f, c);
>>
>> which can never, and should never be called, since no superman_base
>> instances should exist.
> 
> Then why not make _clone() pure virtual as well?

simple: xsd generates it ;)
i would have to change the generated file every time.

/Oliver

From mirhadi at gmail.com  Tue Jul 29 02:12:14 2014
From: mirhadi at gmail.com (Hooman Mirhadi)
Date: Tue Jul 29 02:12:21 2014
Subject: [xsd-users] unsuccessful parse of Siri protocol on linux(x86)
	with g++
In-Reply-To: <boris.20140728130717@codesynthesis.com>
References: <CAP4FVKkw+Z1uF8=35aZgmxvJ=SYmPa6jSB=wv-LJHfLHA+WbkA@mail.gmail.com>
	<boris.20140728130717@codesynthesis.com>
Message-ID: <CAP4FVKm0HaW42QsF8f3vDk16V4NAxnceMf7uhiQrv_9MvAJZfg@mail.gmail.com>

Thanks Boris.
Probably I should spend more time on FAQs before I raise an issue next
time;)


On Mon, Jul 28, 2014 at 9:08 PM, Boris Kolpackov <boris@codesynthesis.com>
wrote:

> Hi Hooman,
>
> Hooman Mirhadi <mirhadi@gmail.com> writes:
>
> > *exception: >< 2 59 >no declaration found for element
> 'p1:ServiceRequest'<*
>
> FAQ 2.1
>
> http://wiki.codesynthesis.com/Tree/FAQ
>
> Boris
>
From boris at codesynthesis.com  Tue Jul 29 05:16:16 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Jul 29 05:21:22 2014
Subject: [xsd-users] no abstract =?utf-8?Q?base?=
	=?utf-8?Q?_classes_with_=22Customizing_the_generated_type_?=
	=?utf-8?B?4oCU?= the complex case"
In-Reply-To: <53D63944.7050903@oli-obk.de>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
Message-ID: <boris.20140729111447@codesynthesis.com>

Hi Oliver,

Oliver Schneider <xsd-users@oli-obk.de> writes:

> simple: xsd generates it ;)

Ah, right ;-).

If you need this support badly enough to be willing to test it,
I am willing to implement it.

Boris

From xsd-users at oli-obk.de  Tue Jul 29 06:52:20 2014
From: xsd-users at oli-obk.de (Oliver Schneider)
Date: Tue Jul 29 06:52:24 2014
Subject: =?windows-1252?Q?Re=3A_=5Bxsd-users=5D_no_abstract_base_?=
	=?windows-1252?Q?classes_with_=22Customizing_the_generated_typ?=
	=?windows-1252?Q?e_=97_the_complex_case=22?=
In-Reply-To: <boris.20140729111447@codesynthesis.com>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
Message-ID: <53D77CE4.4040701@oli-obk.de>

Hi Boris,

Sure thing, it would really help in letting the compiler find bugs (i
just ran into another one (in my code) that caused a runtime exception
instead of a nice compile-time error, exactly due to this issue)
I'll also write a section in the wiki explaining how to use the
xml-abstract + c++-abstract base type.

Removing the _clone function from the intermediate base types won't
solve it though... I guess the biggest issue is the type_factory_map,
which most certainly does not look trivial.

/Oliver

Am 29.07.2014 11:16, schrieb Boris Kolpackov:
> Hi Oliver,
> 
> Oliver Schneider <xsd-users@oli-obk.de> writes:
> 
>> simple: xsd generates it ;)
> 
> Ah, right ;-).
> 
> If you need this support badly enough to be willing to test it,
> I am willing to implement it.
> 
> Boris
> 

From boris at codesynthesis.com  Wed Jul 30 04:24:24 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jul 30 04:29:29 2014
Subject: [xsd-users] no abstract =?utf-8?Q?base?=
	=?utf-8?Q?_classes_with_=22Customizing_the_generated_type_?=
	=?utf-8?B?4oCU?= the complex case"
In-Reply-To: <53D77CE4.4040701@oli-obk.de>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
Message-ID: <boris.20140730102146@codesynthesis.com>

Hi Oliver,

Oliver Schneider <xsd-users@oli-obk.de> writes:

> Removing the _clone function from the intermediate base types won't
> solve it though... I guess the biggest issue is the type_factory_map,
> which most certainly does not look trivial.

Yes, we should not register abstract types in polymorphic maps.

I have this feature implemented and ready for you to test. Would you
like an xsd+dep package or a binary (if so, then for which platform)?

Boris

From boris at codesynthesis.com  Wed Jul 30 04:35:49 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jul 30 04:40:54 2014
Subject: [xsd-users] Type customization and C++11
Message-ID: <boris.20140730103126@codesynthesis.com>

Hi Oliver,

I saw your addition to the type customization guide on using C++11
constructor inheritance:

http://wiki.codesynthesis.com/Tree/Customization_guide

This is really cool, thanks!

The only question I have is don't we still have to re-implement
_clone() functions since the base versions return wrong types?

Boris

From xsd-users at oli-obk.de  Wed Jul 30 04:44:20 2014
From: xsd-users at oli-obk.de (Oliver Schneider)
Date: Wed Jul 30 04:44:23 2014
Subject: =?windows-1252?Q?Re=3A_=5Bxsd-users=5D_no_abstract_base_?=
	=?windows-1252?Q?classes_with_=22Customizing_the_generated_typ?=
	=?windows-1252?Q?e_=97_the_complex_case=22?=
In-Reply-To: <boris.20140730102146@codesynthesis.com>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
	<boris.20140730102146@codesynthesis.com>
Message-ID: <53D8B064.20908@oli-obk.de>

Hi Boris,

I'd prefer the binary (Windows), if it's not too much hazzle.

/Oliver

Am 30.07.2014 10:24, schrieb Boris Kolpackov:
> Hi Oliver,
> 
> Oliver Schneider <xsd-users@oli-obk.de> writes:
> 
>> Removing the _clone function from the intermediate base types won't
>> solve it though... I guess the biggest issue is the type_factory_map,
>> which most certainly does not look trivial.
> 
> Yes, we should not register abstract types in polymorphic maps.
> 
> I have this feature implemented and ready for you to test. Would you
> like an xsd+dep package or a binary (if so, then for which platform)?
> 
> Boris
> 

From boris at codesynthesis.com  Wed Jul 30 05:24:48 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jul 30 05:30:04 2014
Subject: [xsd-users] no abstract =?utf-8?Q?base?=
	=?utf-8?Q?_classes_with_=22Customizing_the_generated_type_?=
	=?utf-8?B?4oCU?= the complex case"
In-Reply-To: <53D8B064.20908@oli-obk.de>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
	<boris.20140730102146@codesynthesis.com>
	<53D8B064.20908@oli-obk.de>
Message-ID: <boris.20140730112403@codesynthesis.com>

Hi Oliver,

Oliver Schneider <xsd-users@oli-obk.de> writes:

> I'd prefer the binary (Windows), if it's not too much hazzle.

Here you go:

http://codesynthesis.com/~boris/tmp/xsd/xsd-4.1.0.a1-i686-windows.zip

Let me know if there are any issues.

Boris

From xsd-users at oli-obk.de  Wed Jul 30 05:39:23 2014
From: xsd-users at oli-obk.de (Oliver Schneider)
Date: Wed Jul 30 05:39:27 2014
Subject: =?windows-1252?Q?Re=3A_=5Bxsd-users=5D_no_abstract_base_?=
	=?windows-1252?Q?classes_with_=22Customizing_the_generated_typ?=
	=?windows-1252?Q?e_=97_the_complex_case=22?=
In-Reply-To: <boris.20140730112403@codesynthesis.com>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
	<boris.20140730102146@codesynthesis.com>
	<53D8B064.20908@oli-obk.de>
	<boris.20140730112403@codesynthesis.com>
Message-ID: <53D8BD4B.9050806@oli-obk.de>

Hi Boris,

the _base classes still have a _clone function (declared and defined)
What are the criteria that make sure they don't exist? maybe i need to
change something in my setup?

/Oliver

Am 30.07.2014 11:24, schrieb Boris Kolpackov:
> Hi Oliver,
> 
> Oliver Schneider <xsd-users@oli-obk.de> writes:
> 
>> I'd prefer the binary (Windows), if it's not too much hazzle.
> 
> Here you go:
> 
> http://codesynthesis.com/~boris/tmp/xsd/xsd-4.1.0.a1-i686-windows.zip
> 
> Let me know if there are any issues.
> 
> Boris
> 

From boris at codesynthesis.com  Wed Jul 30 05:39:44 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jul 30 05:44:49 2014
Subject: [xsd-users] no abstract =?utf-8?Q?base?=
	=?utf-8?Q?_classes_with_=22Customizing_the_generated_type_?=
	=?utf-8?B?4oCU?= the complex case"
In-Reply-To: <53D8BD4B.9050806@oli-obk.de>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
	<boris.20140730102146@codesynthesis.com>
	<53D8B064.20908@oli-obk.de>
	<boris.20140730112403@codesynthesis.com>
	<53D8BD4B.9050806@oli-obk.de>
Message-ID: <boris.20140730113654@codesynthesis.com>

Hi Oliver,

Oliver Schneider <xsd-users@oli-obk.de> writes:

> the _base classes still have a _clone function (declared and defined)
> What are the criteria that make sure they don't exist? 

The type should be defined as abstract in the schema (abstract="true").

Or do you want all "base" classes that result from type customization
to be abstract? If so, I am not 100% sure: it doesn't have to be
derived from. Someone, for example, could use it as a member.

Boris

From xsd-users at oli-obk.de  Wed Jul 30 06:30:36 2014
From: xsd-users at oli-obk.de (Oliver Schneider)
Date: Wed Jul 30 06:30:39 2014
Subject: =?windows-1252?Q?Re=3A_=5Bxsd-users=5D_no_abstract_base_?=
	=?windows-1252?Q?classes_with_=22Customizing_the_generated_typ?=
	=?windows-1252?Q?e_=97_the_complex_case=22?=
In-Reply-To: <boris.20140730113654@codesynthesis.com>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
	<boris.20140730102146@codesynthesis.com>
	<53D8B064.20908@oli-obk.de>
	<boris.20140730112403@codesynthesis.com>
	<53D8BD4B.9050806@oli-obk.de>
	<boris.20140730113654@codesynthesis.com>
Message-ID: <53D8C94C.80502@oli-obk.de>

Hi Boris,

> Or do you want all "base" classes that result from type customization
> to be abstract? If so, I am not 100% sure: it doesn't have to be
> derived from. Someone, for example, could use it as a member.

Yes, that would be necessary.
Using an abstract type for a member is invalid xsd, isn't it?
so only derivation is actually interesting.

/Oliver

From mail at oli-obk.de  Wed Jul 30 05:43:49 2014
From: mail at oli-obk.de (Oliver Schneider)
Date: Wed Jul 30 06:54:11 2014
Subject: =?windows-1252?Q?Re=3A_=5Bxsd-users=5D_no_abstract_base_?=
	=?windows-1252?Q?classes_with_=22Customizing_the_generated_typ?=
	=?windows-1252?Q?e_=97_the_complex_case=22?=
In-Reply-To: <53D8BD4B.9050806@oli-obk.de>
References: <53D60E80.5050409@oli-obk.de>	<boris.20140728130918@codesynthesis.com>	<53D63944.7050903@oli-obk.de>	<boris.20140729111447@codesynthesis.com>	<53D77CE4.4040701@oli-obk.de>	<boris.20140730102146@codesynthesis.com>	<53D8B064.20908@oli-obk.de>	<boris.20140730112403@codesynthesis.com>
	<53D8BD4B.9050806@oli-obk.de>
Message-ID: <53D8BE55.3000208@oli-obk.de>

Ah, nevermind, i just saw what happened.

you removed the implementation of _clone from the abstract class, (the
declaration is still there though, but that's fine, it'd be a linker error)

all _base classes inheriting from an abstract class must also not have a
_clone function.
Am 30.07.2014 11:39, schrieb Oliver Schneider:
> Hi Boris,
>
> the _base classes still have a _clone function (declared and defined)
> What are the criteria that make sure they don't exist? maybe i need to
> change something in my setup?
>
> /Oliver
>
> Am 30.07.2014 11:24, schrieb Boris Kolpackov:
>> Hi Oliver,
>>
>> Oliver Schneider <xsd-users@oli-obk.de> writes:
>>
>>> I'd prefer the binary (Windows), if it's not too much hazzle.
>> Here you go:
>>
>> http://codesynthesis.com/~boris/tmp/xsd/xsd-4.1.0.a1-i686-windows.zip
>>
>> Let me know if there are any issues.
>>
>> Boris
>>

From debian at jff-webhosting.net  Wed Jul 30 08:55:28 2014
From: debian at jff-webhosting.net (=?ISO-8859-1?Q?J=F6rg_Frings-F=FCrst?=)
Date: Wed Jul 30 08:55:32 2014
Subject: [xsd-users] XSD 4.0.0 released
In-Reply-To: <boris.20140722112217@codesynthesis.com>
References: <boris.20140722112217@codesynthesis.com>
Message-ID: <1406724928.6727.4.camel@merkur>

Hello,


Am Dienstag, den 22.07.2014, 11:23 +0200 schrieb Boris Kolpackov:
> Hi,
> 
> We have released XSD 4.0.0. 
[...]

Today XSD was uploaded to Debian unstable.
I have included the patch from [1].


CU
J?rg


[1]
http://scm.codesynthesis.com/?p=xsd/xsd.git;a=commit;h=94cba986108a0e0f42295572ca42c356d59328d7



-- 
pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8  EBCB 422B 44B0 BE58 1B6E
pgp Key: BE581B6E
CAcert Key S/N: 0E:D4:56

J?rg Frings-F?rst
D-54526 Niederkail

Threema: SYR8SJXB

IRC: j_f-f@freenode.net
     j_f-f@oftc.net





-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20140730/4f344944/attachment.pgp
From xsd-users at oli-obk.de  Thu Jul 31 03:37:30 2014
From: xsd-users at oli-obk.de (Oliver Schneider)
Date: Thu Jul 31 03:37:33 2014
Subject: =?windows-1252?Q?Re=3A_=5Bxsd-users=5D_no_abstract_base_?=
	=?windows-1252?Q?classes_with_=22Customizing_the_generated_typ?=
	=?windows-1252?Q?e_=97_the_complex_case=22?=
In-Reply-To: <boris.20140730113654@codesynthesis.com>
References: <53D60E80.5050409@oli-obk.de>
	<boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
	<boris.20140730102146@codesynthesis.com>
	<53D8B064.20908@oli-obk.de>
	<boris.20140730112403@codesynthesis.com>
	<53D8BD4B.9050806@oli-obk.de>
	<boris.20140730113654@codesynthesis.com>
Message-ID: <53D9F23A.3000402@oli-obk.de>

Hi Boris,

Two things occurred to me after a good night's sleep:

> Or do you want all "base" classes that result from type customization
> to be abstract? If so, I am not 100% sure: it doesn't have to be
> derived from. Someone, for example, could use it as a member.

Aren't the *_base classes of complex types required to have a derived
class, even without any abstract (base) classes around?
Or would it be legal to define the _impl class without any base class
and just implement the constructors?

I just manually edited the person.cxx and .hxx files. I made all the
_clone functions in the .hxx file pure virtual, and removed the
implementation in the cxx file, works like a charm.

/Oliver

From boris at codesynthesis.com  Thu Jul 31 04:09:26 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jul 31 04:14:33 2014
Subject: [xsd-users] no abstract =?utf-8?Q?base?=
	=?utf-8?Q?_classes_with_=22Customizing_the_generated_type_?=
	=?utf-8?B?4oCU?= the complex case"
In-Reply-To: <53D9F23A.3000402@oli-obk.de>
References: <boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
	<boris.20140730102146@codesynthesis.com>
	<53D8B064.20908@oli-obk.de>
	<boris.20140730112403@codesynthesis.com>
	<53D8BD4B.9050806@oli-obk.de>
	<boris.20140730113654@codesynthesis.com>
	<53D9F23A.3000402@oli-obk.de>
Message-ID: <boris.20140731100135@codesynthesis.com>

Hi Oliver,

Oliver Schneider <xsd-users@oli-obk.de> writes:

> Aren't the *_base classes of complex types required to have a derived
> class, even without any abstract (base) classes around?
> Or would it be legal to define the _impl class without any base class
> and just implement the constructors?

Yes, exactly. The "base" in type customization means something to base
your implementation on, not necessarily base class as in inheritance.
You could, for example, use the generated implementation as a data member
in your custom implementation.


> I just manually edited the person.cxx and .hxx files. I made all the
> _clone functions in the .hxx file pure virtual, and removed the
> implementation in the cxx file, works like a charm.

I am still not clear what problem we are trying to solve here. The
generated "base" implementations for customized types are not used
directly anywhere in the generated code. I also don't see how anyone
can easily mix the "base" implementation for a custom one -- after
all the base implementation normally has a special name format (for
example, the '_base' suffix). If you wanted to, you could make it
even clearer: '_base_implementation_do_not_use_directly' ;-).

Is it maybe forgetting to implement _clone() that's the problem?

Boris

From xsd-users at oli-obk.de  Thu Jul 31 04:30:15 2014
From: xsd-users at oli-obk.de (Oliver Schneider)
Date: Thu Jul 31 04:30:19 2014
Subject: =?windows-1252?Q?Re=3A_=5Bxsd-users=5D_no_abstract_base_?=
	=?windows-1252?Q?classes_with_=22Customizing_the_generated_typ?=
	=?windows-1252?Q?e_=97_the_complex_case=22?=
In-Reply-To: <boris.20140731100135@codesynthesis.com>
References: <boris.20140728130918@codesynthesis.com>
	<53D63944.7050903@oli-obk.de>
	<boris.20140729111447@codesynthesis.com>
	<53D77CE4.4040701@oli-obk.de>
	<boris.20140730102146@codesynthesis.com>
	<53D8B064.20908@oli-obk.de>
	<boris.20140730112403@codesynthesis.com>
	<53D8BD4B.9050806@oli-obk.de>
	<boris.20140730113654@codesynthesis.com>
	<53D9F23A.3000402@oli-obk.de>
	<boris.20140731100135@codesynthesis.com>
Message-ID: <53D9FE97.2060003@oli-obk.de>

Hi Boris

> Yes, exactly. The "base" in type customization means something to base
> your implementation on, not necessarily base class as in inheritance.
> You could, for example, use the generated implementation as a data member
> in your custom implementation.
Gotcha, but this will be very messy and break the polymorphism. But
there are probably lots of non-polymorphism cases where this is useful.

> I am still not clear what problem we are trying to solve here. The
> generated "base" implementations for customized types are not used
> directly anywhere in the generated code. I also don't see how anyone
> can easily mix the "base" implementation for a custom one -- after
> all the base implementation normally has a special name format (for
> example, the '_base' suffix). If you wanted to, you could make it
> even clearer: '_base_implementation_do_not_use_directly' ;-).
> 
> Is it maybe forgetting to implement _clone() that's the problem?

now we're getting somewhere! (i think we were talking about different
things before :D)

I am implementing _clone in the *_impl classes. Having it also
implemented in the *_base classes requires the *_base classes to be
instanciable (aka not abstract). Since I want to make "print" pure
virtual in "person_impl", and i can only override "print" in the
superman_impl and batman_impl classes, the superman_base and batman_base
classes are abstract (as they don't override "print").
Thus superman_base and batman_base cannot be instanciated in the _clone
function.

So, in addition to your previous fix, and to keep the possibility of
adding the *_base type as a member instead of a base in the
non-polymorphic case, could you either add a command-line argument to
prevent the creation of _clone (manually for every _base class would be
fine), or automatically not create it for polymorphic _base classes?

/Oliver

From boris at codesynthesis.com  Thu Jul 31 06:07:12 2014
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jul 31 06:12:17 2014
Subject: [xsd-users] XSD 4.0.0 released
In-Reply-To: <1406724928.6727.4.camel@merkur>
References: <boris.20140722112217@codesynthesis.com>
	<1406724928.6727.4.camel@merkur>
Message-ID: <boris.20140731120525@codesynthesis.com>

Hi J?rg,

J?rg Frings-F?rst <debian@jff-webhosting.net> writes:

> Today XSD was uploaded to Debian unstable.

That's great news, thanks for your effort! I've sent a message to
the xsd-announcements mailing list and also updated the website and
RSS feed.

http://codesynthesis.com/pipermail/xsd-announcements/2014/000042.html

Boris