From boris at codesynthesis.com  Mon Dec  1 04:36:27 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Element '...' should be un-qualified??
In-Reply-To: <183a50e60811300049x7bde59e2ke670f4ab35769f6f@mail.gmail.com>
References: <183a50e60811300049x7bde59e2ke670f4ab35769f6f@mail.gmail.com>
Message-ID: <20081201093627.GA27711@karelia>

Hi Azadeh,

Azadeh Omrani <a.omrani@gmail.com> writes:

> <xsd:schema targetNamespace="urn:dvb:ipdc:esg:2005"
>   xmlns="urn:dvb:ipdc:esg:2005"
>   xmlns:xsd="http://www.w3.org/2001/XMLSchema" ... >
>
> [...]
>
>   <xsd:element name="ESGMain" type="ESGMainType"/>
>   <xsd:complexType name="ESGMainType">
>     <xsd:sequence>
>       ...
>       <xsd:element name="ESG" type="ESGType" minOccurs="0"/>
>     </xsd:sequence>
>   </xsd:complexType>
>
> the xml instance file is like this:
> 
> <ESGMain xmlns="urn:dvb:ipdc:esg:2005" ... >
>   <ESG>
>
> [...]
>
> Why do you think I get the following  runtime error message (in
> disgnostics_):
>  "Element 'ESG' should be un-qualified" and for all the other elements
>  in the TagretNamespace too...

Your XML document makes "urn:dvb:ipdc:esg:2005" the default 
namespace (xmlns="urn:dvb:ipdc:esg:2005") which means that all
unqualified elements in the document are treated as belonging
to this namespace. But in your schema some local elements
(e.g., ESG) are declared as not belonging to any namespace.

If your intention is to have all elements in your vocabulary
qualified, then you can add elementFormDefault="qualified"
to the xsd:schema element. If local elements should stay
unqualified, then you will need to change your XML document
not to use the default namespace, for example:

<esg:ESGMain xmlns:esg="urn:dvb:ipdc:esg:2005" ...>

 ...

</esg:ESGMain>


> And another question: where can I find the "info" property about each 
> error message?

I am not sure what you mean by this, but check Section 3.3,
"Error Handling" in the C++/Tree Mapping User Manual:

http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#3.3

Boris


From boris at codesynthesis.com  Mon Dec  1 04:49:10 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] XML namespace in generated class?
In-Reply-To: <4931FF4E.1060600@finagle.org>
References: <4931FF4E.1060600@finagle.org>
Message-ID: <20081201094910.GB27711@karelia>

Hi Steve,

Steve Sloan <steve@finagle.org> writes:

> Is there any way to access the schema namespace (i.e. 'targetNamespace') 
> from the corresponding generated classes at runtime?
> 
> I notice that the generated DOM parsing functions check for the 
> appropriate namespace, but use several string constants instead of a 
> const static class member to store it.  Moving the namespace to a 
> class-level constant would also allow for a default namespace map when 
> serializing (and parsing).  Is there a particular reason why it isn't 
> this way now?

It is not done this way at the moment because we generate parsing and
serialization functions (as opposed to classes) for global elements.
As such there is no convenient place to provide access to this 
information.

Having said that, for the next release of XSD we have implemented
an alternative mode where we generate classes instead of functions
for root elements. Besides other useful things, these classes provide
access to element's name and namespace. 

If you would like to give it a try, there is a pre-release binary
(essentially XSD 3.2.0 plus this feature) available for i686 Linux:

http://codesynthesis.com/~boris/tmp/xsd-3.3.0.a1-i686-linux-gnu.tar.bz2

We can also build binaries for other platforms is needed. The NEWS file
entries for this feature are as follows:

  * New option, --generate-element-type, triggers generation of types
    instead of parsing/serialization functions for root elements. This
    is primarily useful to distinguish object models with the same root
    type but with different root elements. For more information refer
    to the messaging example and Section 2.9.1, "Element Types" in the
    C++/Tree Mapping User Manual.

  * New option, --generate-element-map, triggers generation of a root
    element map. The element map allows uniform parsing and serialization
    of multiple root elements. This option can only be used together with
    --generate-element-type. For more information refer to the messaging
    example and Section 2.9.2, "Element Map" in the C++/Tree Mapping
    User Manual.

I suggest that you check the messaging example in examples/cxx/tree/ and
Section 2.9 in the C++/Tree Mapping User Manual located in

documentation/cxx/tree/manual/cxx-tree-manual.pdf

Boris


From boris at codesynthesis.com  Mon Dec  1 07:06:20 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Accessing xml:base: Migration to xsd 3.2.0
In-Reply-To: <23731.80.101.201.227.1227866131.squirrel@webmail.xs4all.nl>
References: <23731.80.101.201.227.1227866131.squirrel@webmail.xs4all.nl>
Message-ID: <20081201120620.GC27711@karelia>

Hi Jeroen,

Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:

> - In file custom-xmlbase/xml-base.cpp[1, item 3][3] I noticed that in
>   constructor 'xml_base::xml_base(::xsd::cxx::tree::type& type,
>   ::xml_schema::flags f)' the call to '::xsd::cxx::xml::dom::parser<
>   wchar_t > p' now takes two additional boolean arguments. I assume
>   based on the code generated by xsd for program explicit[1, top left]
>   that in this case these booleans should be true.  Is this correct?

This is what happens when you rely on implementation details. The
dom::parser class is not really meant for public use. We have made
some optimizations for 3.2.0 and its c-tor has changed to include
two flags indicating whether the element being parsed is expected
to have elements and attributes, respectively.


> - When compiling the sources for programs parser-datamodel[2, bottom
>   left] and parser-anytype[2, bottom right] I get warnings and errors
>   like:
> 
> [...]
> 
>     'xsd::cxx::parser::parser_base<char>' is an ambiguous base of
>     'metadox::foo_type_pimpl'

Hm, this is the result of our work on reducing the use of virtual
inheritance. While it helped a lot in minimizing object code size,
it made the technique that you are using unavailable. I can see
two ways to resolve this off the top of my head. First would be to
override _start_element() and _end_element() in each _pimpl class.

The second approach is to use a class template, for example:

template <typename B>
struct common_base: virtual B
{
  virtual void
  _start_element (const xml_schema::ro_string& ns,
                  const xml_schema::ro_string& n);

  virtual void
  _end_element (const xml_schema::ro_string& ns,
                const xml_schema::ro_string& n);
};

You would then add it to your _pimpl classes like so:

class foo_pimpl: common_base<foo_pskel>
{
  ...
};

Boris


From boris at codesynthesis.com  Mon Dec  1 07:21:28 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Implement arbitrary-precision custom types for schema
	builtin types integer and decimal
In-Reply-To: <4804.80.101.201.227.1227956578.squirrel@webmail.xs4all.nl>
References: <4804.80.101.201.227.1227956578.squirrel@webmail.xs4all.nl>
Message-ID: <20081201122128.GD27711@karelia>

Hi Jeroen,

Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:

> With xsd version 3.2.0, I'm trying to implement arbitrary-precision custom
> types for the schema builtin types integer and decimal, but I'm running
> into some problems.

Your infinite-oldfashioned example is the way it should be
done (there is nothing oldfashioned in this approach, BTW).
The infinite example tries to do it via traits which is only
used when mapping to fundamental C++ types.

Boris


From jnw at xs4all.nl  Mon Dec  1 09:34:39 2008
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Implement arbitrary-precision custom types for 
	schema builtin types integer and decimal
Message-ID: <9793.80.101.201.227.1228142079.squirrel@webmail.xs4all.nl>

Boris Kolpackov <boris@codesynthesis.com> writes:

> Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:
>
>> With xsd version 3.2.0, I'm trying to implement arbitrary-precision
>> custom
>> types for the schema builtin types integer and decimal, but I'm running
>> into some problems.
>
> Your infinite-oldfashioned example is the way it should be
> done (there is nothing oldfashioned in this approach, BTW).
> The infinite example tries to do it via traits which is only
> used when mapping to fundamental C++ types.

All problems have been fixed, and I have completely rewritten the webpage
describing the customization of xsd cxx-parser and cxx-tree for
arbitrary-length numerics. See
http://www.xs4all.nl/~jnw/codesynthesis/arbitrary-precision/

This includes the mapping for cxx-tree using traits, but I did have to
make a small change in the generated code to get it to work. :)

Jeroen.



From Daniel_Macumber at nrel.gov  Mon Dec  1 10:45:41 2008
From: Daniel_Macumber at nrel.gov (Macumber, Daniel)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] xsd namespace confusion for iterator types
Message-ID: <9228D7EC9A32594191AA7530DB531449072D79E4@mail-3a.nrel.gov>

Hello, I am using CodeSynthesis cxx-tree 3.2.0 it looks like some of the
iterator types do not anchor the "xsd::cxx" namespace to the root c++
namespace (e.g. "::xsd::cxx").  This causes the code not to compile if
our target namespace also includes an "xsd".  I was able to fix this
problem by performing the following find and replace on the generated
code:

 

"xsd::cxx::tree::sequence< T >::iterator" ->
"::xsd::cxx::tree::sequence< T >::iterator"

"xsd::cxx::tree::sequence< T >::const_iterator" ->
"::xsd::cxx::tree::sequence< T >::const_iterator"

 

It would be great if this change could make it in to the CodeSynthesis
code for the next release as it is such an easy (presumably) fix.
Thanks a lot, every other indication we've had is that the xsd-cxx tool
is great!

 

Dan Macumber

NREL Commercial Buildings

daniel_macumber@nrel.gov

(303) 384-6172

 

 


From boris at codesynthesis.com  Mon Dec  1 13:39:55 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] xsd namespace confusion for iterator types
In-Reply-To: <9228D7EC9A32594191AA7530DB531449072D79E4@mail-3a.nrel.gov>
References: <9228D7EC9A32594191AA7530DB531449072D79E4@mail-3a.nrel.gov>
Message-ID: <20081201183955.GA32231@karelia>

Hi Daniel,

Macumber, Daniel <Daniel_Macumber@nrel.gov> writes:

> Hello, I am using CodeSynthesis cxx-tree 3.2.0 it looks like some of the
> iterator types do not anchor the "xsd::cxx" namespace to the root c++
> namespace (e.g. "::xsd::cxx").  This causes the code not to compile if
> our target namespace also includes an "xsd".  I was able to fix this
> problem by performing the following find and replace on the generated
> code:
> 
>  
> 
> "xsd::cxx::tree::sequence< T >::iterator" ->
> "::xsd::cxx::tree::sequence< T >::iterator"
> 
> "xsd::cxx::tree::sequence< T >::const_iterator" ->
> "::xsd::cxx::tree::sequence< T >::const_iterator"

This is actually intentional and it has to do with the IntelliSense
support in VC++ 8.0. For some reason it does not like fully-qualified
names here so we had to use the unqualified version as a work-around.
If you remove --generate-intellisense from the command line, everything
should work out of the box (apart from IntelliSense in VC++ 8.0). If
you need the IntelliSense support and cannot upgrade  to VC++ 9.0 then
I am afraid the only way to fix this is to re-map your 'xsd' namespace
to some other name with the help of the --namespace-map option.

> Thanks a lot, every other indication we've had is that the xsd-cxx tool
> is great!

Thanks, I am glad you enjoy it.

Boris


From sww314 at gmail.com  Mon Dec  1 18:12:32 2008
From: sww314 at gmail.com (Scott White)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Turn on xinclude with Xerces-3.0.0 and XSD 3.2.0?
Message-ID: <c63b8540812011512x617f837ey9e76f45b268944f0@mail.gmail.com>

Is there a way to turn on XInclude in the generated code from XSD?
In Xerces, you set a parameter (fgXercesDoXInclude). I did not see any
documentation for a similiar flag on the XSD side.

Thanks-
Scott

From bpringle at sympatico.ca  Mon Dec  1 20:32:08 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Polymorphic problems.
Message-ID: <87prkb4b1j.fsf@sympatico.ca>


In the type-serializer-map.hxx and type-serializer-map.hxx, there is a
map typed to,

   typedef
   std::map<const type_id*, type_info, type_id_comparator>
   type_map;

The STL map only need a function like the 'before' implementation.
The problem (or so I believe) is that code like,

   type_serializer_map::find (const type_id& tid) const
   {
      typename type_map::const_iterator i (type_map_.find (&tid));
      return i == type_map_.end () ? 0 : &i->second;
   }


The &tid is taking a pointer to satisify the 'const type_id*' of the
map.  However, the pointer value (memory address) of the typeid(x) is
not always binary.  This can be true if different shared libaries are
used and the compiler has several RTTI structures for identical type
infos.  The C++ standard has an operator== for the type_info for just
this reason.

I think that the key value in 'type_map' should be changed, as the map
will implicitly do an "type_info* == type_info*" to detect a match
with find().  A copy of the type_info or a string would uniquely
determine the map.  Is that correct?

We are having platform dependent problems with polymorphic
serialization and from debugging, this seems to be the problem.

tia,
Bill Pringlemeir.


From boris at codesynthesis.com  Tue Dec  2 04:59:47 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Turn on xinclude with Xerces-3.0.0 and XSD 3.2.0?
In-Reply-To: <c63b8540812011512x617f837ey9e76f45b268944f0@mail.gmail.com>
References: <c63b8540812011512x617f837ey9e76f45b268944f0@mail.gmail.com>
Message-ID: <20081202095947.GB1977@karelia>

Hi Scott,

Scott White <sww314@gmail.com> writes:

> Is there a way to turn on XInclude in the generated code from XSD?
> In Xerces, you set a parameter (fgXercesDoXInclude). I did not see any
> documentation for a similiar flag on the XSD side.

There is no such flag in XSD. Generally, we follow the rule of
only duplicating the most commonly used Xerces-C++ features and
properties in the XSD interface. For the less frequently used
ones, such as fgXercesDoXInclude, you will need to set up the
XML-to-DOM parsing yourself. This is not difficult to do. Just
take a look at the multiroot example in examples/cxx/tree/. It
includes the code for parsing XML-to-DOM (dom-parser.*) which
you can re-use in your application with some minor adjustments
(e.g., add fgXercesDoXInclude).

Also note that XInclude does not play very well with XML Schema 
validation. If validation is enabled, it will be performed on
the document before XInclude's are processed. This means that
your schema will need to explicitly define all the places in
your vocabulary where inclusion can be performed. Furthermore,
the included fragments are not validated since they may not be
complete enough to be valid.

Boris


From boris at codesynthesis.com  Tue Dec  2 07:31:38 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Polymorphic problems.
In-Reply-To: <87prkb4b1j.fsf@sympatico.ca>
References: <87prkb4b1j.fsf@sympatico.ca>
Message-ID: <20081202123138.GC1977@karelia>

Hi Bill,

Bill Pringlemeir <bpringle@sympatico.ca> writes:

> In the type-serializer-map.hxx and type-serializer-map.hxx, there is a
> map typed to,
> 
>    typedef
>    std::map<const type_id*, type_info, type_id_comparator>
>    type_map;
> 
> The STL map only need a function like the 'before' implementation.
> The problem (or so I believe) is that code like,
> 
>    type_serializer_map::find (const type_id& tid) const
>    {
>       typename type_map::const_iterator i (type_map_.find (&tid));
>       return i == type_map_.end () ? 0 : &i->second;
>    }
> 
> 
> The &tid is taking a pointer to satisify the 'const type_id*' of the
> map.  However, the pointer value (memory address) of the typeid(x) is
> not always binary.  This can be true if different shared libaries are
> used and the compiler has several RTTI structures for identical type
> infos.

The pointers to std::type_info are only used to store references to the
objects and not to compare them. If you look at the implementation of
type_id_comparator (passed as the third template argument to std::map),
you will see that it compares the two objects using the before()
function provided by type_info:

struct type_id_comparator
{
  bool
  operator() (const type_id* x, const type_id* y) const
  {
    return x->before (*y);
  }
};

This means that even if the type_info object in the map and the one
passed to find() are different, the map search should still work
properly (provided the C++ implementation is conformant).


> We are having platform dependent problems with polymorphic
> serialization and from debugging, this seems to be the problem.

Which platform is it? If it is Windows, then it could be the
issue with DLLs and/or the executable having separate maps.
This problem can be resolved with the help of the --export-maps
and --import-maps options. See their documentation in the XSD
Compiler Command Line Manual for details:

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

Boris


From jnw at xs4all.nl  Tue Dec  2 09:54:05 2008
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Accessing xml:base: Migration to xsd 3.2.0
Message-ID: <12004.80.101.201.227.1228229645.squirrel@webmail.xs4all.nl>

Hi Boris,

Boris Kolpackov <boris@codesynthesis.com> wrote:
> Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:
>
>> - In file custom-xmlbase/xml-base.cpp[1, item 3][3] I noticed that in
>>   constructor 'xml_base::xml_base(::xsd::cxx::tree::type& type,
>>   ::xml_schema::flags f)' the call to '::xsd::cxx::xml::dom::parser<
>>   wchar_t > p' now takes two additional boolean arguments. I assume
>>   based on the code generated by xsd for program explicit[1, top left]
>>   that in this case these booleans should be true.  Is this correct?
>
> This is what happens when you rely on implementation details. The
> dom::parser class is not really meant for public use. We have made
> some optimizations for 3.2.0 and its c-tor has changed to include
> two flags indicating whether the element being parsed is expected
> to have elements and attributes, respectively.

Thanks for your clarification. On the web[1], I've changed the description
and the source code accordingly.

A question: For now, I've set both flags to true. I've noticed that it
also seems to work when I set the first flag to false, and the second flag
to true. Should I be using this setting instead?

When I set both flags to false. I get a segmentation error.

>> - When compiling the sources for programs parser-datamodel[2, bottom
>>   left] and parser-anytype[2, bottom right] I get warnings and errors
>>   like:
>>
>> [...]
>>
>>     'xsd::cxx::parser::parser_base<char>' is an ambiguous base of
>>     'metadox::foo_type_pimpl'
>
> Hm, this is the result of our work on reducing the use of virtual
> inheritance. While it helped a lot in minimizing object code size,
> it made the technique that you are using unavailable. I can see
> two ways to resolve this off the top of my head. First would be to
> override _start_element() and _end_element() in each _pimpl class.
>
> The second approach is to use a class template, for example:
>
> template <typename B>
> struct common_base: virtual B
> {
>   virtual void
>   _start_element (const xml_schema::ro_string& ns,
>                   const xml_schema::ro_string& n);
>
>   virtual void
>   _end_element (const xml_schema::ro_string& ns,
>                 const xml_schema::ro_string& n);
> };
>
> You would then add it to your _pimpl classes like so:
>
> class foo_pimpl: common_base<foo_pskel>
> {
>   ...
> };

On the web[2], I've changed the description and the source code to use the
second approach. It seems (in parser-anytype) that I can use the same
template class for both simple and complex types, and also to override
_attribute() and _any_atribute().

For the record: Starting in xsd version 3.1.0.b3, _start_element() takes
three arguments:
    virtual void
    _start_element (const ::xml_schema::ro_string& ns,
                    const ::xml_schema::ro_string& n,
                    const ::xml_schema::ro_string* type);

Thanks for your help!

Jeroen.

[1] http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/index.html
[2] http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/parser.html



From bpringle at sympatico.ca  Tue Dec  2 11:40:21 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Polymorphic problems.
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
Message-ID: <874p1mledm.fsf@sympatico.ca>

On  2 Dec 2008, boris@codesynthesis.com wrote:

> Bill Pringlemeir <bpringle@sympatico.ca> writes:

>> In the type-serializer-map.hxx and type-serializer-map.hxx, there is a
>> map typed to,

>> The &tid is taking a pointer to satisify the 'const type_id*' of the
>> map.  However, the pointer value (memory address) of the typeid(x) is
>> not always binary.  This can be true if different shared libaries are
>> used and the compiler has several RTTI structures for identical type
>> infos.

> The pointers to std::type_info are only used to store references to the
> objects and not to compare them. If you look at the implementation of
> type_id_comparator (passed as the third template argument to std::map),
> you will see that it compares the two objects using the before()
> function provided by type_info:

Right, before fulfills the conditions.  However, there is a hidden
'==' in the find on the primary key which is a pointer.

> This means that even if the type_info object in the map and the one
> passed to find() are different, the map search should still work
> properly (provided the C++ implementation is conformant).

Not really.  It means that the map will construct a tree to find the
non-identical pointers quickly.  If the std::map only uses the
'before' functionality, then how does find() know when it has found an
identical value versus one that is !before() or after?  find must use
the '==' operator on the primary key.  I don't know of a standard, etc
that mentions this, but it *IS* impossible to implement 'find()'
without an operator '==' on the primary key.

>> We are having platform dependent problems with polymorphic
>> serialization and from debugging, this seems to be the problem.

> Which platform is it?

The platform is AIX with xlC.  I do think that someone had posted a
similar problem with Windows DLL's.  They couldn't give you a good
test case and came up with some other work around.

The following test case demonstrates the problem.  This fails on
various versions of gcc.  However for the type-serializer-map.[th]xx
to fail, the platform must have typeid() that return different
pointers.

[start test]
#include <iostream>
#include <map>
#include <string.h>

std::map<char *, std::string> theMap;

struct type_id_comparator
{
    bool
    operator() (const char* x, const char* y) const
        {
            return x < y;
        }
};

int main(void)
{
    char *key1 = "key1";
    char *key2 = "key2";
    char *key3 = "key3";
    char *key4 = "key4";

    theMap.insert(std::make_pair(key1, std::string(key1)));
    theMap.insert(std::make_pair(key2, std::string(key2)));
    theMap.insert(std::make_pair(key3, std::string(key3)));
    theMap.insert(std::make_pair(key4, std::string(key4)));

    char *compare = new char[5];
    strcpy(compare, key1);
        
    if(theMap.find(compare) != theMap.end() )
    {
        std::cout << "We have a match." << std::endl;
    }
    else
    {
        std::cout << "No match." << std::endl;
    }

    if(theMap.find("key1") != theMap.end() )
    {
        std::cout << "We have a match." << std::endl;
    }
    else
    {
        std::cout << "No match." << std::endl;
    }
    
    printf("key1: %p compare: %p value: %p\n", key1, compare, "key1"); 
                                       
    return 0;
}
[end test]

Regards,
Bill Pringlemeir.

-- 
How do we make long-term thinking automatic and common instead of
difficult and rare? - Stewart Brand


From bpringle at sympatico.ca  Tue Dec  2 11:40:56 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Polymorphic problems.
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
Message-ID: <87wseijzs7.fsf@sympatico.ca>

On  2 Dec 2008, boris@codesynthesis.com wrote:

> Bill Pringlemeir <bpringle@sympatico.ca> writes:

>> In the type-serializer-map.hxx and type-serializer-map.hxx, there is a
>> map typed to,

>> The &tid is taking a pointer to satisify the 'const type_id*' of the
>> map.  However, the pointer value (memory address) of the typeid(x) is
>> not always binary.  This can be true if different shared libaries are
>> used and the compiler has several RTTI structures for identical type
>> infos.

> The pointers to std::type_info are only used to store references to the
> objects and not to compare them. If you look at the implementation of
> type_id_comparator (passed as the third template argument to std::map),
> you will see that it compares the two objects using the before()
> function provided by type_info:

Right, before fulfills the conditions.  However, there is a hidden
'==' in the find on the primary key which is a pointer.

> This means that even if the type_info object in the map and the one
> passed to find() are different, the map search should still work
> properly (provided the C++ implementation is conformant).

Not really.  It means that the map will construct a tree to find the
non-identical pointers quickly.

>> We are having platform dependent problems with polymorphic
>> serialization and from debugging, this seems to be the problem.

> Which platform is it?

The platform is AIX with xlC.  I do think that someone had posted a
similar problem with Windows DLL's.  They couldn't give you a good
test case and came up with some other work around.

The following test case demonstrates the problem.  This fails on
various versions of gcc.  However for the type-serializer-map.[th]xx
to fail, the platform must have typeid() that return different
pointers.

[start test]
#include <iostream>
#include <map>
#include <string.h>

std::map<char *, std::string> theMap;

struct type_id_comparator
{
    bool
    operator() (const char* x, const char* y) const
        {
            return x < y;
        }
};

int main(void)
{
    char *key1 = "key1";
    char *key2 = "key2";
    char *key3 = "key3";
    char *key4 = "key4";

    theMap.insert(std::make_pair(key1, std::string(key1)));
    theMap.insert(std::make_pair(key2, std::string(key2)));
    theMap.insert(std::make_pair(key3, std::string(key3)));
    theMap.insert(std::make_pair(key4, std::string(key4)));

    char *compare = new char[5];
    strcpy(compare, key1);
        
    if(theMap.find(compare) != theMap.end() )
    {
        std::cout << "We have a match." << std::endl;
    }
    else
    {
        std::cout << "No match." << std::endl;
    }

    if(theMap.find("key1") != theMap.end() )
    {
        std::cout << "We have a match." << std::endl;
    }
    else
    {
        std::cout << "No match." << std::endl;
    }
    
    printf("key1: %p compare: %p value: %p\n", key1, compare, "key1"); 
                                       
    return 0;
}
[end test]

-- 
How do we make long-term thinking automatic and common instead of
difficult and rare? - Stewart Brand

-- 
I believe  that sex is one  of the most  beautiful, natural, wholesome
things that money can buy. - Steve Martin


From boris at codesynthesis.com  Tue Dec  2 10:59:06 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Polymorphic problems.
In-Reply-To: <874p1mledm.fsf@sympatico.ca>
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
	<874p1mledm.fsf@sympatico.ca>
Message-ID: <20081202155906.GG1977@karelia>

Hi Bill,

Bill Pringlemeir <bpringle@sympatico.ca> writes:

> Not really.  It means that the map will construct a tree to find the
> non-identical pointers quickly.  If the std::map only uses the
> 'before' functionality, then how does find() know when it has found an
> identical value versus one that is !before() or after?

When (!before (x, y) && !before (y, x)), x == y.


> The following test case demonstrates the problem.  This fails on
> various versions of gcc.  However for the type-serializer-map.[th]xx
> to fail, the platform must have typeid() that return different
> pointers.
> 
> [...]
> 
> std::map<char *, std::string> theMap;
> 
> struct type_id_comparator
> {
>     bool
>     operator() (const char* x, const char* y) const
>         {
>             return x < y;
>         }
> };

This is not how type-serializer-map works. To make it emulate
type-serializer-map, this code needs to be changed like so:


struct type_id_comparator
{
    bool
    operator() (const char* x, const char* y) const
    {
      return strcmp (x, y) < 0;
    }
};

std::map<char *, std::string, type_id_comparator> theMap;

That is, we need to use strcmp() instead of comparing pointers
as well as pass type_id_comparator as the third template argument
to std::map.

I tested this program with both g++ on GNU/Linux and XL C++ 7.0
on AIX. In both cases it prints "We have a match." twice.

This means that std::map in XL C++ works as expected and the
problem is somewhere else. Would it be possible for you to
come up with a test case that demonstrates the problem on AIX
with XL C++? Something that recreates your shared object
structure but uses dummy schemas?

Thanks,
Boris


From a.omrani at gmail.com  Tue Dec  2 12:38:01 2008
From: a.omrani at gmail.com (Azadeh Omrani)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] xsd app portability ,...
Message-ID: <183a50e60812020938i4c2230dayb50034778692e53a@mail.gmail.com>

Hi,

Is that easy to start using xsd in windows application and test it on PC
environment, then port it to mobile platform?
or we need to re generate the application using xsd/e?

Sorry for sending my questions to your email Boris. I used reply button
carelessly.

Bests
Azadeh

From bpringle at sympatico.ca  Tue Dec  2 15:13:46 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Polymorphic problems.
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
	<874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia>
Message-ID: <87myfemj2d.fsf@sympatico.ca>

On  2 Dec 2008, boris@codesynthesis.com wrote:
> Bill Pringlemeir <bpringle@sympatico.ca> writes:

>> If the std::map only uses the 'before' functionality, then how does
>> find() know when it has found an identical value versus one that is
>> !before() or after?

> When (!before (x, y) && !before (y, x)), x == y.

Hmm.  Very right!

>> The following test case demonstrates the problem.  This fails on
>> various versions of gcc.  However for the type-serializer-map.[th]xx
>> to fail, the platform must have typeid() that return different
>> pointers.

[snip]

> This is not how type-serializer-map works. To make it emulate
> type-serializer-map, this code needs to be changed like so:

> struct type_id_comparator
> {
> bool
> operator() (const char* x, const char* y) const
> {
> return strcmp (x, y) < 0;
> }
> };

Sorry, I was being lazy.  gcc implements it with pointer comparison,
but I see that it has a particular comment saying that the type_infos
are gaurenteed to be identical.  AIX has,

inline bool type_info::before(const type_info&x) const {
  return (&x!=this) && (strcmp(x.mangledName,this->mangledName)>=0);
}

However, I made your change and I still get the following output,

bpringle@pvr:~$ g++ -Wall test.cc -o test; ./test
No match.
We have a match.
key1: 0x804a070 compare: 0x804c0e8 value: 0x804a070
bpringle@pvr:~$ g++ -DTEST_STR -Wall test.cc -o test; ./test
We have a match.
We have a match.
key1: 0xbfa499cc compare: 0xbfa499bc value: 0x804a490
bpringle@pvr:~$ g++ --version
g++ (GCC) 4.2.0
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

With gcc 3.4.6 I have different std::string addresses, but the same
results for std::string.  Did you make other changes?  I looked at the
gcc implementation of the map and you are correct.  It seems that
'(!before (x, y) && !before (y, x))' is used... but I still get the
output above.  I tried different variants of the strcmp and never got
the pointers to work.  I think you are correct that it should work;
but can you let me know why it is not?  It must still be an error in
my test code.

> This means that std::map in XL C++ works as expected and the
> problem is somewhere else. Would it be possible for you to
> come up with a test case that demonstrates the problem on AIX
> with XL C++? Something that recreates your shared object
> structure but uses dummy schemas?

We have xlC version 6.0.  Maybe this is not supported.  I am pretty
sure that this is the problem in our system.  We have put debug in
type-serializer-map.txx and the class is registered, the same class
name is used during a serialization attempt from another module, but
the no_type_info exception is thrown.

It (no_type_info exceptions) seems to happen with polymorphic
customizations on AIX.  The same exception is not thrown on Linux.  I
will try to work on a test case; it is rather difficult as I don't
understand the problem.  I believe that it is serializing a customized
child.  The schema source lives in a seperate shared library and the
executable creates the object and attempts to serialize it.  The
no_type_info is only thrown on AIX.  It could also be with static
initializers... although the routine is well into the main line...

Thanks again,
Bill Pringlemeir.

-- 
Programming is like sex. One mistake and you have to support it for the
rest of your life. - Michael Sinz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cc
Type: text/x-c++src
Size: 1377 bytes
Desc: A test file.
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20081202/1345cfc4/test.cc
From bpringle at sympatico.ca  Tue Dec  2 21:09:06 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Polymorphic problems.
In-Reply-To: <87myfemj2d.fsf@sympatico.ca> (Bill Pringlemeir's message of
	"Tue, 02 Dec 2008 15:13:46 -0500")
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
	<874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia>
	<87myfemj2d.fsf@sympatico.ca>
Message-ID: <87k5aij9h9.fsf@sympatico.ca>

On  2 Dec 2008, bpringle@sympatico.ca wrote:

> It (no_type_info exceptions) seems to happen with polymorphic
> customizations on AIX.  The same exception is not thrown on Linux.
> I will try to work on a test case; it is rather difficult as I don't
> understand the problem.  I believe that it is serializing a
> customized child.  The schema source lives in a seperate shared
> library and the executable creates the object and attempts to
> serialize it.  The no_type_info is only thrown on AIX.  It could
> also be with static initializers... although the routine is well
> into the main line...

I have just modified the polymorphism examples to 'wrap' the batman
class.  This seems to give the serialization error, on Linux even.
This is a similar setup.  Is some type_serialize/type_factory static
or extra methods in the wrapped class to support serialization.

I have this working reliably for a class where '--custom_type foo' is
used.  Ie, I created the complete class by myself; although, those are
simpleType.  When I put some debug in type-serialization-map.txx, the
type is '11batman_base'.

The custom implementation of batman_base seems to mix batman and
batman_base in the static initializers.  A larger system seems to make
this work on Linux.  Perhaps our classes have more conversion
operators that are allowing the compiler to match a template, etc.
But this doesn't work for XL C++.

Is the attached test case sufficient?  The make rules are not
completely correct.  It lives beside the polymorphism example in the
cxx/tree directory of xsd-3.2.0.

tia,
Bill Pringlemeir.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: polymorphism.tar.gz
Type: application/octet-stream
Size: 2565 bytes
Desc: test for wrapped children
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20081202/7a1a0e83/polymorphism.tar.obj
From jafb at tinet.org  Tue Dec  2 21:05:58 2008
From: jafb at tinet.org (Juan Antonio =?iso-8859-1?Q?Farr=E9_Basurte?=)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Incompatibility between xsd rpm and mono in Fedora 10
Message-ID: <36143.87.219.168.228.1228269958.squirrel@webmail.tinet.org>



Hi,
I've just downloaded XSD RPM package for x86 linux and tried to install it in my Fedora 10 Linux distribution.
When I try to install
the RPM, it reports a conflict with the mono-web package. To be able to install XSD, I've needed to uninstall all the mono system.
Do you know
any better solution?
Thanks in advance

From boris at codesynthesis.com  Wed Dec  3 01:27:06 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:06 2009
Subject: [xsd-users] Incompatibility between xsd rpm and mono in Fedora 10
In-Reply-To: <36143.87.219.168.228.1228269958.squirrel@webmail.tinet.org>
References: <36143.87.219.168.228.1228269958.squirrel@webmail.tinet.org>
Message-ID: <20081203062706.GA12327@karelia>

Hi Juan,

Juan Antonio Farr? Basurte <jafb@tinet.org> writes:

> I've just downloaded XSD RPM package for x86 linux and tried to install
> it in my Fedora 10 Linux distribution. When I try to install the RPM,
> it reports a conflict with the mono-web package. To be able to install
> XSD, I've needed to uninstall all the mono system. Do you know any better
> solution?

Mono includes a binary analogous to Microsoft's 'xsd.exe' which they
renamed 'xsd'. It is an XML Schema compiler for .NET and as far as I
know it is not very widely used. So if you don't use 'xsd.exe' in
Mono yourself, you can simply instruct rpm to override the conflicting
file by providing the --replacefiles option. No other applications
in Mono will be affected by this since xsd.exe is normally invoked
by developers.

Boris


From boris at codesynthesis.com  Wed Dec  3 01:42:35 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] xsd app portability ,...
In-Reply-To: <183a50e60812020938i4c2230dayb50034778692e53a@mail.gmail.com>
References: <183a50e60812020938i4c2230dayb50034778692e53a@mail.gmail.com>
Message-ID: <20081203064235.GC12327@karelia>

Hi Azadeh,

Azadeh Omrani <a.omrani@gmail.com> writes:

> Is that easy to start using xsd in windows application and test it on PC
> environment, then port it to mobile platform? 

This depends on which mobile platform you are planning to target. If
it is Windows CE-based then it may not work though we had reports that
with Windows CE 6 it is possible to use XSD with some minor modifications
(e.g., remove the use of C++ locales).


> or we need to re generate the application using xsd/e?

With XSD/e you can definitely do the development on Windows and then use
the same code to target one of the mobile/embedded platforms (including
various versions of Windows CE). Note, however, that you cannot simply
"re generate the application" from XSD to XSD/e since XSD/e is quite a
bit different compared to XSD. You will need to be developing with XSD/e
from the start.

Boris


From boris at codesynthesis.com  Wed Dec  3 01:52:46 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Accessing xml:base: Migration to xsd 3.2.0
In-Reply-To: <12004.80.101.201.227.1228229645.squirrel@webmail.xs4all.nl>
References: <12004.80.101.201.227.1228229645.squirrel@webmail.xs4all.nl>
Message-ID: <20081203065246.GE12327@karelia>

Hi Jeroen,

Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:

> A question: For now, I've set both flags to true. I've noticed that it
> also seems to work when I set the first flag to false, and the second flag
> to true. Should I be using this setting instead?

If the type has elements, then the first flag should be true. If the
type has attributes, then the second flag should be true.

Boris


From boris at codesynthesis.com  Wed Dec  3 03:18:09 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Polymorphic problems.
In-Reply-To: <87k5aij9h9.fsf@sympatico.ca>
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
	<874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia>
	<87myfemj2d.fsf@sympatico.ca> <87k5aij9h9.fsf@sympatico.ca>
Message-ID: <20081203081809.GG12327@karelia>

Hi Bill,

Bill Pringlemeir <bpringle@sympatico.ca> writes:

> The custom implementation of batman_base seems to mix batman and
> batman_base in the static initializers.  

Yes, this is exactly what happens. We register batman_base in the
parsing map and batman in the serialization map and, as a result,
typeid's don't match. This is definitely a bug and I fixed it for
the next release of XSD. If your would like, I can build you a pre-
release binary(ies) with the fix. Just let me know which platform(s)
you need.

Thanks for your help in getting to the bottom of this!

Boris

P.S. At the end of supermen_wrapper.cxx you have this code fragment
which is not needed:

#include <ostream>
#include <xsd/cxx/xml/dom/serialization-source.hxx>
#include <xsd/cxx/tree/error-handler.hxx>

#include <xsd/cxx/tree/type-serializer-map.hxx>

namespace _xsd
{
  static
  const ::xsd::cxx::tree::type_serializer_plate< 0, char >
  type_serializer_plate_init;
}


From aamir.mohammad at aon.ca  Wed Dec  3 14:48:50 2008
From: aamir.mohammad at aon.ca (aamir.mohammad@aon.ca)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] XML validation problems
Message-ID: <OFB4FA74F4.5FEA2348-ON85257514.006C6731-85257514.006CD378@notes.aonad.ca>

The XSD C++/Tree documentation uses the following XML as an example:

<?xml version="1.0"?>
<hello xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:noNamespaceSchemaLocation="hello.xsd">
  <greeting>Hi</greeting>
  <name>sun</name>
</hello>


I want to be able to parse XML with the following format:

<?xml version="1.0"?>
<hello>
  <greeting>Hi</greeting>
  <name>sun</name>
</hello>


Is this possible?  I don't want to have to include xmlns stuff.  Ideally I 
would like to be able to drop the <?xml version="1.0"?> part as well, so 
that I am able to parse the following text:

<hello>
  <greeting>Hi</greeting>
  <name>sun</name>
</hello>


Thanks,
Aamir



**********************************************************************************
This communication (and any attachments) is directed in confidence to the addressee(s) listed above, and may not otherwise be distributed, copied or used.  The contents of this communication may also be subject to privilege, and all rights to that privilege are expressly claimed and not waived.  If you have received this communication in error, please notify us by reply e-mail or by telephone and delete this communication (and any attachments) without making a copy.  Thank you.

***************
La pr?sente communication (et tout fichier rattach?) s'adresse uniquement au(x) destinataire(s) pr?cit?(s) et ne peut ?tre autrement distribu?e, copi?e ou utilis?e.  Le contenu de cette communication peut ?tre assujetti au privil?ge.  Tout droit ? ce privil?ge est express?ment revendiqu? et nullement abandonn?.  Si vous avez re?u cette communication par erreur, veuillez nous en avertir imm?diatement en r?pondant ? ce courriel ou en nous appelant.  Veuillez ?galement effacer cette communication (et tout fichier rattach?) sans en conserver une copie.  Merci.
From boris at codesynthesis.com  Wed Dec  3 15:18:44 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] XML validation problems
In-Reply-To: <OFB4FA74F4.5FEA2348-ON85257514.006C6731-85257514.006CD378@notes.aonad.ca>
References: <OFB4FA74F4.5FEA2348-ON85257514.006C6731-85257514.006CD378@notes.aonad.ca>
Message-ID: <20081203201844.GA16138@karelia>

Hi Aamir,

aamir.mohammad@aon.ca <aamir.mohammad@aon.ca> writes:

> The XSD C++/Tree documentation uses the following XML as an example:
> 
> <?xml version="1.0"?>
> <hello xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>        xsi:noNamespaceSchemaLocation="hello.xsd">
>   <greeting>Hi</greeting>
>   <name>sun</name>
> </hello>
> 
> I want to be able to parse XML with the following format:
> 
> <?xml version="1.0"?>
> <hello>
>   <greeting>Hi</greeting>
>   <name>sun</name>
> </hello>
> 
> 
> Is this possible?  I don't want to have to include xmlns stuff.

Yes, you can parse this XML. You will, however, need to either
disable XML Schema validation in the underlying XML parser or
supply the schema information in an alternative way. For details,
please see Section 5.1, "XML Schema Validation and Searching" in
the C++/Tree Mapping User Guide:

http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#5.1


> Ideally I would like to be able to drop the <?xml version="1.0"?>
> part as well, so that I am able to parse the following text:
> 
> <hello>
>   <greeting>Hi</greeting>
>   <name>sun</name>
> </hello>

XML declaration (that's what this part is called) is optional so
there shouldn't be any problem with removing it.

Boris


From bpringle at sympatico.ca  Wed Dec  3 18:15:42 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Polymorphic problems.
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
	<874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia>
	<87myfemj2d.fsf@sympatico.ca> <87k5aij9h9.fsf@sympatico.ca>
	<20081203081809.GG12327@karelia>
Message-ID: <87zljcx335.fsf@sympatico.ca>

On  3 Dec 2008, boris@codesynthesis.com wrote:

> Bill Pringlemeir <bpringle@sympatico.ca> writes:

>> The custom implementation of batman_base seems to mix batman and
>> batman_base in the static initializers.

> Yes, this is exactly what happens. We register batman_base in the
> parsing map and batman in the serialization map and, as a result,
> typeid's don't match. This is definitely a bug and I fixed it for
> the next release of XSD. If your would like, I can build you a pre-
> release binary(ies) with the fix. Just let me know which platform(s)
> you need.

I have used a make rule to do the same thing (I think).  It boils down
to the sed script,

  sed -e -i 's+\(::xsd::cxx::tree::type_factory_initializer.*char,  \)\([A-Za-z][A-Za-z]*\)_base >$+\1\2 >+' $@

Is that the correct fix to remove the '_base' from the
type_factory_initializer?  Or is the fix more involved.  For my simple
test case, this seems to correct the problem on Linux.  

However, I still have issues with AIX; AIX throws the no_type_info
exception. I was using CXX=xlC_r CXXFLAGS=-qrtti=all for the XL C++
options.  Do you have this problem with XL C++ as well?

Can you think of any more issues that using the '--custom-type
batman=/batman_base' with polymorphism might cause.  There are no
other methods that the batman class needs to implement, or global
operators?  Or are the XSD changes more extensive that the simple sed
line I used above?

Regards,
Bill Pringlemeir.

-- 
I find this continuous feedback and interplay between pure mathematics
and theoretical physics most fascinating. - Marco


From boris at codesynthesis.com  Thu Dec  4 09:28:19 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Polymorphic problems.
In-Reply-To: <87zljcx335.fsf@sympatico.ca>
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
	<874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia>
	<87myfemj2d.fsf@sympatico.ca> <87k5aij9h9.fsf@sympatico.ca>
	<20081203081809.GG12327@karelia> <87zljcx335.fsf@sympatico.ca>
Message-ID: <20081204142819.GA13539@karelia>

Hi Bill,

Bill Pringlemeir <bpringle@sympatico.ca> writes:

> I have used a make rule to do the same thing (I think).  It boils down
> to the sed script,
> 
> [...]
> 
> Is that the correct fix to remove the '_base' from the
> type_factory_initializer?

I think that should do it.


> However, I still have issues with AIX; AIX throws the no_type_info
> exception. I was using CXX=xlC_r CXXFLAGS=-qrtti=all for the XL C++
> options.  Do you have this problem with XL C++ as well?

Yes, I could reproduce it with XL C++ 7.0. After some instrumentation,
it appears that the type_info::before() implementation provide by
XL C++ on AIX is buggy. It returns true for two different type_info
objects that point to the same type. It is actually quite obvious
why when one examines the implementation you have shown before:

inline bool type_info::before(const type_info&x) const {
  return (&x!=this) && (strcmp(x.mangledName,this->mangledName)>=0);
}

The last comparison should be >, not >=.

I've come up with a work around for this problem which makes the
test run as expected on AIX. The changes are only to libxsd so
you can apply them to your copy of XSD 3.2.0:

http://codesynthesis.com/~boris/tmp/xsd-3.2.0-xlc-aix.patch

> Can you think of any more issues that using the '--custom-type
> batman=/batman_base' with polymorphism might cause.  There are no
> other methods that the batman class needs to implement, or global
> operators?

No, the test looks fine. The only thing I had to do is add public:
to make the members in supermen_wrapper.h accessible.

Boris


From bpringle at sympatico.ca  Thu Dec  4 13:45:04 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Polymorphism enhancements. [was: Polymorphic problems.]
In-Reply-To: <20081204142819.GA13539@karelia> (Boris Kolpackov's message of
	"Thu, 4 Dec 2008 16:28:19 +0200")
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
	<874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia>
	<87myfemj2d.fsf@sympatico.ca> <87k5aij9h9.fsf@sympatico.ca>
	<20081203081809.GG12327@karelia> <87zljcx335.fsf@sympatico.ca>
	<20081204142819.GA13539@karelia>
Message-ID: <87iqpzeq4v.fsf_-_@sympatico.ca>


On  4 Dec 2008, boris@codesynthesis.com wrote:

> I've come up with a work around for this problem which makes the
> test run as expected on AIX. The changes are only to libxsd so
> you can apply them to your copy of XSD 3.2.0:

> http://codesynthesis.com/~boris/tmp/xsd-3.2.0-xlc-aix.patch

Thanks Boris.  This seems to resolve all of our problems.  

I have some suggestions (mainly for polymorphism code generation).

1. I have had some problems with constructors with a single arguement.
   This will be used as conversion values by the compiler.  This is
   especially problematic with simpleType extentions.  However, I have
   found that customizing the simpleType with '--custom-type foo' was
   often necessary, so I get the chance to use explicit in the
   wrapper.  Users always have the option to do this.

2. In the polymorphism example, if person complex type and the
   reference element are declared with 'abstract="true"', the same
   code is generated no matter what.  It would be nice if the person
   base had a pure virtual destructor and the type-factory-map.txx
   supported base objects that cann't be created.  I believe that this
   is possible as in instance documents we would have a different tag
   name or xs:type attribute.  This allows a way to specify ABC in
   schema notation, which seems to be the intent of 'abtract'.  This
   would be most helpful in preventing mistakes where an ABC is
   serialized.

3. It is possible that a schema will have many similar data types with
   the same defaults.  Would it be possible to use the same default
   static instance in generated code.  Ie, if we have 20 "xs:int
   default='0'" attributes, then twenty static elements are created.

4. Consider the schma below.  Processing with XSD defaults creates
   only one constructor.  Add '--generate-base-ctor' and we have two.
   Use '--generate-polymorphic' and we have *four* constructors.  This
   is due to the auto_ptr interface needed by 'e3'.  Also, these
   constructors are fairly expensive as the constructors set many of
   the attributes to defaults.  Attributes are better (from a code
   generation perspective) than elements because optional/default does
   not require constructor arguments (passing all the values creates
   more code).  Couldn't xsd generate a private 'setDefaults()' for
   the derived class and call this within the body?  Alternatively,
   more control over the 'auto_ptr' mechanism that allows selective
   generation of constructors would help.

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:simpleType name="fromSimple">
    <xs:restriction base="xs:long"/>
  </xs:simpleType>


  <xs:complexType name="attrOnly">
    <xs:sequence>
      <xs:element name="e1" type="xs:int"/>
    </xs:sequence>
    <xs:attribute name="a1" type="fromSimple" default="0" />
    <xs:attribute name="a2" type="xs:dateTime" default="1970-01-01T00:00:00" />
    <xs:attribute name="a3" type="xs:string" default="" />
    <xs:attribute name="a4" type="xs:byte" default="0" />
    <xs:attribute name="a5" type="xs:float" default="0.0" />
  </xs:complexType>

  <xs:complexType name="derived">
    <xs:complexContent>
      <xs:extension base="attrOnly">
      <xs:sequence>
        <xs:element name="e2" type="xs:long"/>
          <xs:element name="e3" type="xs:dateTime"/>
          </xs:sequence>
          <xs:attribute name="a6" type="fromSimple" default="0" />
          <xs:attribute name="a7" type="xs:dateTime" default="1970-01-01T00:00:00" />
          <xs:attribute name="a8" type="xs:string" default="" />
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>
<!-- -*- mode: xml;-*- -->

Thanks once again!
Bill Pringlemeir.

-- 
I never did give anybody hell.  I just told the truth and they thought
it was hell. - Harry S. Truman


From bpringle at sympatico.ca  Thu Dec  4 14:05:20 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Makefile rules.
Message-ID: <87bpvrep73.fsf@sympatico.ca>


I use the following steps an automatic depends for XSD code
generation,

The steps are,

1. For each schema create a make variable denoting schema depends
keyed to the filename.
   a) the schema always depends on itself.
   b) scan the schema for schemaLocation, extract the file name and
      add the *make variable* for that schema.

After this step, the make variables will expand to complete the schema
depends.  Schemas files should have a DAG structure so the make
variable should not be recursive.

2. Create an empty rule so that make doesn't try to recreate schemas.

3. Make all source, headers and inline files dependant on the schema
   variable.

This seems to work well.  I think that it is dependant on our use of
'include' within the schema, but I think it could be extended to
create code generation rules for most systems.

fwiw,
Bill Pringlemeir.


From debcamp6415 at gmail.com  Thu Dec  4 22:07:52 2008
From: debcamp6415 at gmail.com (Debbie Campbell)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] How to build xsd?
Message-ID: <16aa9b550812041907q773d2f18k2896e27206d18930@mail.gmail.com>

The latest linux source xsd-3.2.0-i686-linux-gnu.tar.bz2 does not seem to
contain any makefiles or config files for building xsd from the source
(although there are makefiles for the examples).  How does one build xsd
from the source?



Thanks,

--Debbie Campbell

From boris at codesynthesis.com  Fri Dec  5 00:43:11 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] How to build xsd?
In-Reply-To: <16aa9b550812041907q773d2f18k2896e27206d18930@mail.gmail.com>
References: <16aa9b550812041907q773d2f18k2896e27206d18930@mail.gmail.com>
Message-ID: <20081205054311.GA19964@karelia>

Hi Debbie,

Debbie Campbell <debcamp6415@gmail.com> writes:

> The latest linux source xsd-3.2.0-i686-linux-gnu.tar.bz2 does not seem to
> contain any makefiles or config files for building xsd from the source
> (although there are makefiles for the examples).  How does one build xsd
> from the source?

The file you mentioned above contains a pre-built binary of the XSD
compiler as well as the source code and makefiles for the examples.
If you would like to build XSD from scratch, you will need to download
the source distribution (xsd-3.2.0.tar.bz2). The link to this package
as well as other developer-oriented information is provided on the XSD
project page:

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

In particular, you may be interested in the build instructions:

UNIX/Linux: 

http://www.codesynthesis.com/projects/xsd/extras/build-unix.xhtml

Windows:

http://www.codesynthesis.com/projects/xsd/extras/build-windows.xhtml

Boris


From boris at codesynthesis.com  Fri Dec  5 03:43:25 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Re: Polymorphism enhancements. [was: Polymorphic
	problems.]
In-Reply-To: <87iqpzeq4v.fsf_-_@sympatico.ca>
References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia>
	<874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia>
	<87myfemj2d.fsf@sympatico.ca> <87k5aij9h9.fsf@sympatico.ca>
	<20081203081809.GG12327@karelia> <87zljcx335.fsf@sympatico.ca>
	<20081204142819.GA13539@karelia> <87iqpzeq4v.fsf_-_@sympatico.ca>
Message-ID: <20081205084325.GC20354@karelia>

Hi Bill,

Bill Pringlemeir <bpringle@sympatico.ca> writes:

> 1. I have had some problems with constructors with a single arguement.
>    This will be used as conversion values by the compiler.  This is
>    especially problematic with simpleType extentions.  However, I have
>    found that customizing the simpleType with '--custom-type foo' was
>    often necessary, so I get the chance to use explicit in the
>    wrapper.  Users always have the option to do this.

I am not sure adding explicit to all single-argument c-tors is a 
good idea. Consider, for example, this fairly common situation:

<simpleType name="int_t">
  <restriction base="int"/>
</simpleType>

<xs:complexType name="type">
  <xs:sequence>
    <xs:element name="i" type="int_t"/>
  </xs:sequence>
</xs:complexType>

Right now one can write:

type t (10);

If we add explicit, then one will need to write:

type t (int_t (10));

We can always add an option (e.g., --generate-explicit) for this but
I am wondering how useful it will be.


> 2. In the polymorphism example, if person complex type and the
>    reference element are declared with 'abstract="true"', the same
>    code is generated no matter what.  It would be nice if the person
>    base had a pure virtual destructor and the type-factory-map.txx
>    supported base objects that cann't be created.  I believe that this
>    is possible as in instance documents we would have a different tag
>    name or xs:type attribute.  This allows a way to specify ABC in
>    schema notation, which seems to be the intent of 'abtract'.  This
>    would be most helpful in preventing mistakes where an ABC is
>    serialized.

Yes, we can do this. I've added it to the TODO list.


> 3. It is possible that a schema will have many similar data types with
>    the same defaults.  Would it be possible to use the same default
>    static instance in generated code.  Ie, if we have 20 "xs:int
>    default='0'" attributes, then twenty static elements are created.

Do you mean the same private value (in order to save space) or the 
same public accessors for these values?


> 4. Consider the schma below.  Processing with XSD defaults creates
>    only one constructor.  Add '--generate-base-ctor' and we have two.
>    Use '--generate-polymorphic' and we have *four* constructors.  This
>    is due to the auto_ptr interface needed by 'e3'.  Also, these
>    constructors are fairly expensive as the constructors set many of
>    the attributes to defaults.  Attributes are better (from a code
>    generation perspective) than elements because optional/default does
>    not require constructor arguments (passing all the values creates
>    more code).  Couldn't xsd generate a private 'setDefaults()' for
>    the derived class and call this within the body?

Yes, this is already on our TODO list. We plan to analyze the overhead
and see if adding a common init() function will help. 


> Alternatively, more control over the 'auto_ptr' mechanism that allows
> selective generation of constructors would help.

Not sure how this can be done. Specifying a set of c-tors to generate
for each type sounds too burdensome.

Thanks for all the suggestions!

Boris


From boris at codesynthesis.com  Fri Dec  5 04:05:33 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Makefile rules.
In-Reply-To: <87bpvrep73.fsf@sympatico.ca>
References: <87bpvrep73.fsf@sympatico.ca>
Message-ID: <20081205090533.GD20354@karelia>

Hi Bill,

We have considered automatically generating makefile dependencies
for a long time now. For some reason nobody seems to be interested
in this feature. Basically, if you have b.xsd include a.xsd, you
will get something like this for b.xsd:

b.hxx b.cxx: b.xsd a.xsd

It will be trivial to do from the XSD compiler. All we need is to
figure out all the little details, e.g.,

- generating only dependencies as well as together with the C++
  code

- option to suppress inclusion of imported schemas in the 
  dependencies

- option to generate do-nothing rules for schemas (so that one
  can remove a schema and still run make)

- allow to specify header and schema path prefixes (and probably
  regex'es for more advanced transformations)

Let me know if you would be interested in something like this.

Boris


From rlischner at proteus-technologies.com  Fri Dec  5 15:04:00 2008
From: rlischner at proteus-technologies.com (Ray Lischner)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Makefile rules.
References: <87bpvrep73.fsf@sympatico.ca> <20081205090533.GD20354@karelia>
Message-ID: <F1886AFB628EA94098943970F1563B89012B7C43@LINUS.proteus-technologies.com>

I don't think we could use that feature. When we compile schemas, we package the generated files, put them up in a repository, and other projects pull them down and unpackage them in a different directory. Each pull may use a different directory. The xsd compiler knows nothing about the destination directories, so it could not produce meaningful dependencies.
 
It's a good idea, however, and I think many other projects would be able to make use of this feature.
 
Ray Lischner,
Senior Member of Technical Staff
133 National Business Pkwy, Ste 150      t. 443.539.3448
Annapolis Junction, MD 20701                c. 410.854.5170
rlischner@proteus-technologies.com         f. 443.539.3370
 
This electronic message and any files transmitted with it contain information
which may be privileged and/or proprietary. The information is intended for use
solely by the intended recipient(s). If you are not the intended recipient, be
aware that any disclosure, copying, distribution or use of this information is
prohibited. If you have received this electronic message in error, please advise
the sender by reply email or by telephone (443.539.3400) and delete the message. 

________________________________

From: xsd-users-bounces@codesynthesis.com on behalf of Boris Kolpackov
Sent: Fri 12/5/2008 4:05 AM
To: Bill Pringlemeir
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] Makefile rules.



Hi Bill,

We have considered automatically generating makefile dependencies
for a long time now. For some reason nobody seems to be interested
in this feature. Basically, if you have b.xsd include a.xsd, you
will get something like this for b.xsd:

b.hxx b.cxx: b.xsd a.xsd

It will be trivial to do from the XSD compiler. All we need is to
figure out all the little details, e.g.,

- generating only dependencies as well as together with the C++
  code

- option to suppress inclusion of imported schemas in the
  dependencies

- option to generate do-nothing rules for schemas (so that one
  can remove a schema and still run make)

- allow to specify header and schema path prefixes (and probably
  regex'es for more advanced transformations)

Let me know if you would be interested in something like this.

Boris




From bpringle at sympatico.ca  Fri Dec  5 14:20:16 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Makefile rules.
In-Reply-To: <20081205090533.GD20354@karelia> (Boris Kolpackov's message of
	"Fri, 5 Dec 2008 11:05:33 +0200")
References: <87bpvrep73.fsf@sympatico.ca> <20081205090533.GD20354@karelia>
Message-ID: <87ljuumntb.fsf@sympatico.ca>

On  5 Dec 2008, boris@codesynthesis.com wrote:

> We have considered automatically generating makefile dependencies
> for a long time now. For some reason nobody seems to be interested
> in this feature. Basically, if you have b.xsd include a.xsd, you
> will get something like this for b.xsd:

[snip]

> Let me know if you would be interested in something like this.

I have my makefiles do this using sed, etc.  By using make variable
expansion, you only have to scan the one file.  The other depends will
be chained.

I think that knowing what is a dependency in the generated code is
worth documenting.  Even for 'static' make rules.

If 'a' includes 'b' includes 'c'.  I guess that the complete include
chain is needed.   Ie,

a.cxx a.hxx : a.xsd b.xsd c.xsd

It is fairly easy for people to make static make rules or script their
own to do this dynamically.  All of the caveats that XSD would have to
handle can be implicit in the makefiles...  That is probably why no
one has requested it.

fwiw,
Bill Pringlemeir.

-- 
Finish your beer -- there are sober people in China!


From PaquetP at navcanada.ca  Mon Dec  8 10:24:59 2008
From: PaquetP at navcanada.ca (Paquette, Patrick)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Complex Custom types
Message-ID: <474534909BE4064E853161350C47578E0A8B6C56@ncrmail1.corp.navcan.ca>

--history lesson--
I'm implementing a messaging protocol between two systems, and I have
the luxury of defining the communication mechanism and the protocol.

The two systems are: VxWorks realtime OS <-> C# .Net GUI

We started using our own custom ASCII protocol, where the model was
represented in C++ classes that compiled in both (what MS calls)
"native" C++ and .NET C++.  If anyone out there ever had to do this -
it's macro hell.  Don't do it!

So, we're abandoning this approach, and moving to XML.  .NET has their
own "xsd", but for the Real time system, we're going to use
Codesynthesis XSD.

The approach is working great, but I hit a bump in the road.
--end history lesson--

>From the example on the wiki, when types are inherited from in the same
schema, it mentions to use class templates when implementing your custom
class.  To quote:

"when types being customized are inherited from in the same schema file,
we cannot include definitions of custom types at the end of the
genearted header file..."
 "...Since the custom type definitions are included before the generated
base types (person_base, superman_base, and batman_base) are defined we
have to use class templates instead of plain classes ".

I'm trying to avoid the need to define the custom types as template
classes, as I "believe" I shouldn't have to (this is where I'm probably
wrong, but let's see what everybody else says...)
Since I'm defining the schema used between the two systems (it's not
given to me by a 3rd party), I've decided not to put it all in one
schema file.  The base "Message" complex type is defined in
"Message_base.xsd", and all sub messages are defined in "Message.xsd",
and "Message.xsd" xsd:includes Message_base.xsd.
I compile them seperately with the following Makefile:
XML_FILES := message.cxx \
             message_base.cxx

CUSTOM_TYPES := --custom-type Diagnose=/Diagnose_base \
                --custom-type Message=/Message_base
                
ROOT_ELEMENTS := --root-element message \
                 --root-element message_result 

.PHONY: quick
quick : $(XML_FILES)

$(XML_FILES): %.cxx: %.xsd
	xsdx.exe cxx-tree --output-dir . --generate-serialization
--generate-polymorphic --generate-intellisense $(ROOT_ELEMENTS)
$(CUSTOM_TYPES) --hxx-epilogue '#include "$*.hpp"' $<

clean:
	rm *.?xx 

So I just use the -hxx-epilogue to include a .hpp file that defines the
customization, for each .xsd.  I don't have the problem of the example
in the WIKI because the derived types are in a different XSD.

If I want to define a custom class for the XSD types, I write .hpp/.cpp
files for that type, add it to my CUSTOM_TYPES, and it all just works.
The problem I'm having is in the type_factory_initializer in the
message.cxx file that is generated:

static
const ::xsd::cxx::tree::type_factory_initializer< 0, char, Diagnose_base
>
_xsd_Diagnose_base_type_factory_init (
  "Diagnose",
  "");

When I parse a Message that has a "Diagnose" message in it, it creates a
new instance of Diagnose_base instead of Diagnose - which I don't want.

If I change the 3rd argument of the template initializaiton from
Diagnose_base to Diagnose, everything works great...but then I'm
modifying generated source...

Is there a flag I'm missing to have this done by xsd?  Could this be a
bug?  Am I using this tool in a way it was never intended?

I really don't want to have to use dynamic_cast to check the message
type and call my message handler from that, I'd rather use a virtual
"handle" function in Message...

Any input would be greatfull.

Patrick Paquette
Programmer
Nav Canada - Flight Inspection Engineering
Technical Systems Center
280 Hunt Club Road
Ottawa, ON
K1V 1C1
(613) 248-6939


-------------- next part --------------
A non-text attachment was scrubbed...
Name: schema.zip
Type: application/x-zip-compressed
Size: 23995 bytes
Desc: schema.zip
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20081208/1b891751/schema.bin
From PaquetP at navcanada.ca  Mon Dec  8 10:45:02 2008
From: PaquetP at navcanada.ca (Paquette, Patrick)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] RE: Complex Custom types
Message-ID: <474534909BE4064E853161350C47578E0A8B6C57@ncrmail1.corp.navcan.ca>

I just read Bill Pringlemeir and Boris' thread on the Polymorphic
enhancements...

Boris, I'll take a copy of the pre-release if your giving it out ;)
Thanks!

Patrick


From boris at codesynthesis.com  Mon Dec  8 10:47:48 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Complex Custom types
In-Reply-To: <474534909BE4064E853161350C47578E0A8B6C56@ncrmail1.corp.navcan.ca>
References: <474534909BE4064E853161350C47578E0A8B6C56@ncrmail1.corp.navcan.ca>
Message-ID: <20081208154748.GD6502@karelia>

Hi Patrick,

Paquette, Patrick <PaquetP@navcanada.ca> writes:

> --history lesson--
> [...]
> --end history lesson--

Thanks for the heads up.


> I'm trying to avoid the need to define the custom types as template
> classes, as I "believe" I shouldn't have to (this is where I'm probably
> wrong, but let's see what everybody else says...)

No, you are quite right. If you can split your schemas on the 
inheritance boundaries, then you don't need the template approach.


> static
> const ::xsd::cxx::tree::type_factory_initializer< 0, char, Diagnose_base >
> _xsd_Diagnose_base_type_factory_init (
>   "Diagnose",
>   "");
> 
> When I parse a Message that has a "Diagnose" message in it, it creates a
> new instance of Diagnose_base instead of Diagnose - which I don't want.
> 
> If I change the 3rd argument of the template initializaiton from
> Diagnose_base to Diagnose, everything works great...but then I'm
> modifying generated source...
> 
> Is there a flag I'm missing to have this done by xsd?  Could this be a
> bug?  Am I using this tool in a way it was never intended?

This is a bug that was also discovered by Bill Pringlemeir just a few
days ago:

http://codesynthesis.com/pipermail/xsd-users/2008-December/002086.html

The type in the factory init code above should be Diagnose, not 
Diagnose_base. We have fixed this problem for the next release of
XSD and I can build you a pre-release binary with the fix if you
would like (just let me know which platform(s) you need).

Alternatively, you can use Bill's little sed script to fix this up
in the generated code until XSD 3.3.0 is out:

http://codesynthesis.com/pipermail/xsd-users/2008-December/002094.html

Boris


From rlischner at proteus-technologies.com  Mon Dec  8 15:57:50 2008
From: rlischner at proteus-technologies.com (Ray Lischner)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] <any> and xerces cloneNode
Message-ID: <F1886AFB628EA94098943970F1563B89012B7C49@LINUS.proteus-technologies.com>

I need to handle an <any> element. To make it easier, I defined a new complex type whose sole content is <any>, so I have only this type to customize. I customized the type to store the any content in a a DOMNode.
 
The default constructor stores a null pointer, of course. The copy constructor and assignment operator call cloneNode(source, true) to make a deep copy of the <any> element and its subelements. I overload operator<<(DOMElement&, MyType) to call importNode so I can copy the <any> element into the destination DOM.
 
But it doesn't work. I keep getting memory errors. I commented out all calls to release(), just to make sure I didn't have a logic error that resulted in a double-free. So I should have some memory leaks, but no other problems. Still, I get segfaults from inside cloneNode(). What am I doing wrong? (I'm still using Code Synthesis 2.3.1, with Xerces 2.7.)
 
The class looks something like this:
 
class Any : public AnyBase {
public:
   Any() : AnyBase(), any_(0) {}
  ~Any() {}
  Any(const xercesc::DOMElement& dom, xml_schema::flags f=0, xml_schema::type* c=0)
  : AnyBase(dom, f, c), any_(dom.getFirstChild())
  {}
  Any(Any const& other, xml_schema::flags f=0, xml_schema::type* c=0)
  : Any(other, f, c), any_(other.any())
  {}
  Any& operator=(Any const& other) {
    static_cast<AnyBase&>(*this) = other;
    any(other.any());
    return *this;
  }
  virtual Any* _clone(xml_schema::flags f=0, xml_schema::type* c = 0) const { return new Any(*this, f, c); }
 
  xercesc::DOMNode* any() { return any_; }
  xercesc::DOMNode const* any() const { return any_; }
  void any(xercesc::DOMNode const* any) { any_ = any ? any->cloneNode() : 0; }
private:
  xercesc::DOMNode* any_;
};
 
void operator<<(xercesc::DOMElement& e, Any& a)
{
  e << static_cast<AnyBase const&>(a);
  if (a.any() != 0) {
    xercesc::DOMNode* n = e.getOwnerDocument()->importNode(a.any());
    e.appendChild(n);
  }
}
 
Ray Lischner,
Senior Member of Technical Staff
133 National Business Pkwy, Ste 150      t. 443.539.3448
Annapolis Junction, MD 20701                c. 410.854.5170
rlischner@proteus-technologies.com         f. 443.539.3370
 
This electronic message and any files transmitted with it contain information
which may be privileged and/or proprietary. The information is intended for use
solely by the intended recipient(s). If you are not the intended recipient, be
aware that any disclosure, copying, distribution or use of this information is
prohibited. If you have received this electronic message in error, please advise
the sender by reply email or by telephone (443.539.3400) and delete the message. 

From bpringle at sympatico.ca  Mon Dec  8 18:23:39 2008
From: bpringle at sympatico.ca (Bill Pringlemeir)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Makefile rules.
In-Reply-To: <87ljuumntb.fsf@sympatico.ca> (Bill Pringlemeir's message of
	"Fri, 05 Dec 2008 14:20:16 -0500")
References: <87bpvrep73.fsf@sympatico.ca> <20081205090533.GD20354@karelia>
	<87ljuumntb.fsf@sympatico.ca>
Message-ID: <87abb6i744.fsf@sympatico.ca>

On  5 Dec 2008, bpringle@sympatico.ca wrote:
On  5 Dec 2008, boris@codesynthesis.com wrote:

>> We have considered automatically generating makefile dependencies
>> for a long time now. For some reason nobody seems to be interested
>> in this feature. Basically, if you have b.xsd include a.xsd, you
>> will get something like this for b.xsd:

> [snip]

>> Let me know if you would be interested in something like this.

> [snip]

> It is fairly easy for people to make static make rules or script their
> own to do this dynamically.  All of the caveats that XSD would have to
> handle can be implicit in the makefiles...  That is probably why no
> one has requested it.

Arrgh!  Maybe I would like this feature.  gmake v3.81 doesn't accept this,

default: $(DEP_Service)
         @echo $^

second: test

# start chain
DEP_MessageBase = MessageBase.xsd
DEP_Record      = Record.xsd
DEP_Service     = Service.xsd $(DEP_MessageBase) $(DEP_Record)
# end chain

test: $(DEP_Service)
      @echo $^

Somehow recursive variables in the target seems to be broken; or I
have a mis-understanding.  Also, it seems that schema notation allows
for cyclic includes which I can never handle with recursive variables.

Things are even more bizarre with gmake when the 'chain' portion is a
dependant makefile.  Ie. 'include schema.d'.  I don't seem to be able
to relocate the variable declarations [there are a lot of other gnu
make features in the mix; static patterns, order-only, macros, etc].

Fwiw,
Bill Pringlemeir.


From boris at codesynthesis.com  Tue Dec  9 04:34:33 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] <any> and xerces cloneNode
In-Reply-To: <F1886AFB628EA94098943970F1563B89012B7C49@LINUS.proteus-technologies.com>
References: <F1886AFB628EA94098943970F1563B89012B7C49@LINUS.proteus-technologies.com>
Message-ID: <20081209093433.GA12008@karelia>

Hi Ray,

Ray Lischner <rlischner@proteus-technologies.com> writes:

> But it doesn't work. I keep getting memory errors. 

The way Xerces-C++ works, a DOMNode instance always belongs to
some DOMDocument. We implement wildcard mapping in XSD 3-series
by including a private DOMDocument object into each type that has
a wildcard. This document contains all the DOM nodes corresponding
to the wildcard content.

Your code, on the other hand, simply stores a pointer to the the
DOM node that belongs to the DOMDocument being parsed. This will
only work if you maintain DOM association which implies that the
DOM document is guaranteed to be available for as long as the
object model. Otherwise, your object model points to a DOMNode
that is destroyed as soon as parsing is finished.

If you are not maintaining the DOM association, then your code 
needs a major rework. I suggest that you grab XSD 3.2.0, compile
your Any type with --generate-wildcard, and copy the wildcard
storage logic to your XSD 2.3.1 code.

If you are maintaining the DOM association, then:

>   : AnyBase(dom, f, c), any_(dom.getFirstChild())

This is actually dangerous, since the first child can be a 
whitespace-only text node.


>   Any(Any const& other, xml_schema::flags f=0, xml_schema::type* c=0)
>   : Any(other, f, c), any_(other.any())

This is a shallow copy, which means the new instance will point to
the DOM node in another object model.


> void any(xercesc::DOMNode const* any) { any_ = any ? any->cloneNode() : 0; }

Unless you know for sure that 'any' belongs to the same document 
as the one associated with the object model, you will need to use 
importNode() here.


> void operator<<(xercesc::DOMElement& e, Any& a)
> {
>   e << static_cast<AnyBase const&>(a);
>   if (a.any() != 0) {
>     xercesc::DOMNode* n = e.getOwnerDocument()->importNode(a.any());

You will need to pass true as the second argument to make sure it
is a recursive copy:

xercesc::DOMNode* n = e.getOwnerDocument()->importNode(a.any(), true);

Boris


From boris at codesynthesis.com  Tue Dec  9 04:47:43 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Makefile rules.
In-Reply-To: <87abb6i744.fsf@sympatico.ca>
References: <87bpvrep73.fsf@sympatico.ca> <20081205090533.GD20354@karelia>
	<87ljuumntb.fsf@sympatico.ca> <87abb6i744.fsf@sympatico.ca>
Message-ID: <20081209094743.GB12008@karelia>

Hi Bill,

Bill Pringlemeir <bpringle@sympatico.ca> writes:

> Arrgh!  Maybe I would like this feature.

Ok, we will try to implement this for 3.3.0.

> gmake v3.81 doesn't accept this,
> 
> default: $(DEP_Service)
>          @echo $^
> 
> # start chain
> DEP_MessageBase = MessageBase.xsd
> DEP_Record      = Record.xsd
> DEP_Service     = Service.xsd $(DEP_MessageBase) $(DEP_Record)
> # end chain

I get the same (expected) result with 3.80 and 3.81. The prerequisites
list is expanded when the makefile is read, so you need to assign
values to variables (recursive or not) that are referenced in that
list before the rule.


> Also, it seems that schema notation allows for cyclic includes
> which I can never handle with recursive variables.

That's true.

Boris


From dawhite32 at gmail.com  Wed Dec 10 15:05:07 2008
From: dawhite32 at gmail.com (David White)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Undefined reference error
Message-ID: <97823d5c0812101205y662a34ecy5e9a8b57247ab3b3@mail.gmail.com>

Dear Boris and xsd-users,

Thanks for an excellent XML C++ binding tool.

I am stuck on a problem I cannot solve - I would appreciate your help.  In
short, I am having problems compiling the driver source (generated by XSD
cxx-parser) into a win32 exe - the problem seems to be in linking Xerces-c++
library which I built using GCC on Windows (via MinGW + MSYS).  Here is a
summary of what I have done to date:

Compile using pre-built MSVC8 library:
1. Installed xsd-3.2.msi successfully.
2. Using cxx-parser, created:
   + mymodel-pimpl.hxx/cxx
   + mymodel-pskel.hxx/cxx
   + mymodel-driver.cxx
via cmd line (see attached make_cpp_h):
xsd cxx-parser --xml-parser xerces --generate-print-impl
--generate-test-driver --root-element MMXmlFormat --output-dir
"./cxx-parser" mymodel.xsd

3. Successfully compiled and ran mymodel-driver.cxx in MSVC8.  OK.


Try to compile using gcc-built xerces library:
1. Download xerces-c-3.0.0 source.
2. Configure and make using MinGW and MSYS, via:

$ export XERCESROOT="D:\\downloads\\xerces\\xerces-c-3.0.0\\"
$ ./configure --enable-transcoder-windows --host=i686-mingw32
LDFLAGS=-no-undefined CPPFLAGS="-DXERCES_BUILDING_LIBRARY
-DXERCES_USE_TRANSCODER_WINDOWS -DXERCES_USE_WIN32_MSGLOADER
-DXERCES_USE_NETACCESSOR_WINSOCK -DXERCES_USE_FILEMGR_WINDOWS
-DXERCES_USE_MUTEXMGR_WINDOWS -DXERCES_PATH_DELIMITER_BACKSLASH
-DHAVE_STRICMP -DHAVE_STRNICMP -DHAVE_LIMITS_H -DHAVE_SYS_TIMEB_H
-DHAVE_FTIME -DHAVE_WCSUPR -DHAVE_WCSLWR -DHAVE_WCSICMP -DHAVE_WCSNICMP"
(see attached run_config)

NOTE: Followed instructions in
http://xerces.apache.org/xerces-c/build-3.html
NOTE: Preprocessor definitions obtained from MSVC8 vcproj file
NOTE: xerces-c-3.0.0 compiles with no errors.

3. Create c++ project in Eclipse (and NetBeans) and include:
   + mymodel-pimpl.hxx/cxx
   + mymodel-pskel.hxx/cxx
   + mymodel-driver.cxx
   + xercex-c library (built via gcc above)

7. On compile, the following error is produced:

undefined reference to
`_imp___ZN11xercesc_3_017SAXParseExceptionC1EPKtS2_S2_jjPNS_13MemoryManagerE'

Why?  What I don't understand is that the pre-built Windows .lib file for
MSVCx links successfully in MSVCx projects, whereas the gcc-built library I
created does not link in gcc-based projects.

I would be extremely grateful for any help you can provide.

Thanks in advance.

Kind regards, David.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run_config
Type: application/octet-stream
Size: 995 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20081211/ed35bfbe/run_config.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_cpp_h
Type: application/octet-stream
Size: 164 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20081211/ed35bfbe/make_cpp_h.obj
From boris at codesynthesis.com  Wed Dec 10 15:34:24 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Undefined reference error
In-Reply-To: <97823d5c0812101205y662a34ecy5e9a8b57247ab3b3@mail.gmail.com>
References: <97823d5c0812101205y662a34ecy5e9a8b57247ab3b3@mail.gmail.com>
Message-ID: <20081210203424.GB18636@karelia>

Hi David,

David White <dawhite32@gmail.com> writes:

> Try to compile using gcc-built xerces library:
> 1. Download xerces-c-3.0.0 source.
> 2. Configure and make using MinGW and MSYS, via:
> 
> $ export XERCESROOT="D:\\downloads\\xerces\\xerces-c-3.0.0\\"
> $ ./configure --enable-transcoder-windows --host=i686-mingw32
> LDFLAGS=-no-undefined CPPFLAGS="-DXERCES_BUILDING_LIBRARY
> -DXERCES_USE_TRANSCODER_WINDOWS -DXERCES_USE_WIN32_MSGLOADER
> -DXERCES_USE_NETACCESSOR_WINSOCK -DXERCES_USE_FILEMGR_WINDOWS
> -DXERCES_USE_MUTEXMGR_WINDOWS -DXERCES_PATH_DELIMITER_BACKSLASH
> -DHAVE_STRICMP -DHAVE_STRNICMP -DHAVE_LIMITS_H -DHAVE_SYS_TIMEB_H
> -DHAVE_FTIME -DHAVE_WCSUPR -DHAVE_WCSLWR -DHAVE_WCSICMP -DHAVE_WCSNICMP"
> (see attached run_config)
> 
> NOTE: Followed instructions in
> http://xerces.apache.org/xerces-c/build-3.html
> NOTE: Preprocessor definitions obtained from MSVC8 vcproj file
> NOTE: xerces-c-3.0.0 compiles with no errors.

I think your problem is with the Xerces-C++ build. First of all,
you don't need any of the preprocessor defines -- the build system
will determine which ones are required automatically (and by defining
those that are not required, you can actually end up with a broken
build).

Secondly, I suggest that you start with a static library since it
appears that MinGW has problems with DLL building more often than
not. If that works, you can try to build a DLL and see how it goes.
So to build libxerces-c.lib, do the following (you don't need to
set XERCESROOT anymore):

$ ./configure --disable-shared LDFLAGS=-no-undefined 
$ make

Let me know if this doesn't help.

Boris


From raptor_cg at yahoo.com  Wed Dec 10 18:22:03 2008
From: raptor_cg at yahoo.com (Chris Gonzales)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Compile issue
Message-ID: <280451.52631.qm@web111516.mail.gq1.yahoo.com>

To who it may concern,

  I'm using xsd. I can generate my classes on windows and use the generated code with no issues; however, when I port to an older system that is not iso complient I recieve multiples of these types of errors while compiling the generated classes:

"../xsd/cxx/tree/elements.hxx", line 722.24: CCN5296 (S) A return value of type "std::auto_ptr<xsd::cxx::tree::_type::dom_info>" 
cannot be initialized with an rvalue of type "std::auto_ptr<xsd::cxx::tree::_type::dom_info>".

example line for error in question:
          if (cn == 0)
              return auto_ptr<dom_info> (0);

I have been able to find a work around using:
              return std::auto_ptr_ref<dom_info>(auto_ptr<dom_info> (0));

However, there are so many such as these I was wondering if there is a compile option or alternative to haveing to root through and adapt to run on this older compile.

Thanks,
Chris



      


From boris at codesynthesis.com  Thu Dec 11 03:02:29 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Compile issue
In-Reply-To: <280451.52631.qm@web111516.mail.gq1.yahoo.com>
References: <280451.52631.qm@web111516.mail.gq1.yahoo.com>
Message-ID: <20081211080229.GF19801@karelia>

Hi Chris,

Chris Gonzales <raptor_cg@yahoo.com> writes:

> "../xsd/cxx/tree/elements.hxx", line 722.24: CCN5296 (S) A return value of type "std::auto_ptr<xsd::cxx::tree::_type::dom_info>" 
> cannot be initialized with an rvalue of type "std::auto_ptr<xsd::cxx::tree::_type::dom_info>".
> 
> example line for error in question:
>           if (cn == 0)
>               return auto_ptr<dom_info> (0);
> 
> I have been able to find a work around using:
>               return std::auto_ptr_ref<dom_info>(auto_ptr<dom_info> (0));
> 

A customer reported a similar problem with IBM XL C++ on z/OS. I
believe you are also using this configuration. That customer solved
this by upgrading to a newer version of the C++ compiler.

We can also try to work around this problem in our code. However,
before resorting to using auto_ptr_ref directly, could you try
to change:

return auto_ptr<dom_info> (0);

to

auto_ptr<dom_info> r (0);
return r;

And let me know if this gets rid of the compiler error?

Thank you,
Boris


From dawhite32 at gmail.com  Thu Dec 11 07:42:00 2008
From: dawhite32 at gmail.com (David White)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Undefined reference error
In-Reply-To: <20081210203424.GB18636@karelia>
References: <97823d5c0812101205y662a34ecy5e9a8b57247ab3b3@mail.gmail.com>
	<20081210203424.GB18636@karelia>
Message-ID: <97823d5c0812110442s44f1fb67o9513552e70147902@mail.gmail.com>

Hi Boris,

thanks for your reply.  Unfortunately, rebuilding xerces as you suggest
below did not solve the problem.  Rather, I now have 12 undefined
references.

Kind regards, David.

On Thu, Dec 11, 2008 at 6:34 AM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Hi David,
>
> David White <dawhite32@gmail.com> writes:
>
> > Try to compile using gcc-built xerces library:
> > 1. Download xerces-c-3.0.0 source.
> > 2. Configure and make using MinGW and MSYS, via:
> >
> > $ export XERCESROOT="D:\\downloads\\xerces\\xerces-c-3.0.0\\"
> > $ ./configure --enable-transcoder-windows --host=i686-mingw32
> > LDFLAGS=-no-undefined CPPFLAGS="-DXERCES_BUILDING_LIBRARY
> > -DXERCES_USE_TRANSCODER_WINDOWS -DXERCES_USE_WIN32_MSGLOADER
> > -DXERCES_USE_NETACCESSOR_WINSOCK -DXERCES_USE_FILEMGR_WINDOWS
> > -DXERCES_USE_MUTEXMGR_WINDOWS -DXERCES_PATH_DELIMITER_BACKSLASH
> > -DHAVE_STRICMP -DHAVE_STRNICMP -DHAVE_LIMITS_H -DHAVE_SYS_TIMEB_H
> > -DHAVE_FTIME -DHAVE_WCSUPR -DHAVE_WCSLWR -DHAVE_WCSICMP -DHAVE_WCSNICMP"
> > (see attached run_config)
> >
> > NOTE: Followed instructions in
> > http://xerces.apache.org/xerces-c/build-3.html
> > NOTE: Preprocessor definitions obtained from MSVC8 vcproj file
> > NOTE: xerces-c-3.0.0 compiles with no errors.
>
> I think your problem is with the Xerces-C++ build. First of all,
> you don't need any of the preprocessor defines -- the build system
> will determine which ones are required automatically (and by defining
> those that are not required, you can actually end up with a broken
> build).
>
> Secondly, I suggest that you start with a static library since it
> appears that MinGW has problems with DLL building more often than
> not. If that works, you can try to build a DLL and see how it goes.
> So to build libxerces-c.lib, do the following (you don't need to
> set XERCESROOT anymore):
>
> $ ./configure --disable-shared LDFLAGS=-no-undefined
> $ make
>
> Let me know if this doesn't help.
>
> Boris
>

From boris at codesynthesis.com  Thu Dec 11 09:40:42 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Undefined reference error
In-Reply-To: <97823d5c0812110442s44f1fb67o9513552e70147902@mail.gmail.com>
References: <97823d5c0812101205y662a34ecy5e9a8b57247ab3b3@mail.gmail.com>
	<20081210203424.GB18636@karelia>
	<97823d5c0812110442s44f1fb67o9513552e70147902@mail.gmail.com>
Message-ID: <20081211144042.GB24951@karelia>

Hi David,

David White <dawhite32@gmail.com> writes:

> thanks for your reply.  Unfortunately, rebuilding xerces as you suggest
> below did not solve the problem.  Rather, I now have 12 undefined
> references.

Ok, I just tried to build everything from scratch and everything
works fine. I am using a fairly recent MinGW+MSYS (g++ 3.4.5 r3).
Here is what I did in the MSYS console:

$ tar xfz xerces-c-3.0.0.tar.gz
$ cd xerces-c-3.0.0
$ ./configure --disable-shared LDFLAGS=-no-undefined CFLAGS=-O0 CXXFLAGS=-O0
$ make
$ cd ..
$ unzip -q xsd-3.2.0-i686-windows.zip
$ cd xsd-3.2.0-i686-windows/examples/cxx/parser/library
$ make CPPFLAGS=-I../../../../../xerces-c-3.0.0/src \
LDFLAGS=-L../../../../../xerces-c-3.0.0/src/.libs

The example compiles, links and runs fine. Can you try this exact build
commands and see if it works for you?

Boris


From debcamp6415 at gmail.com  Thu Dec 11 12:06:49 2008
From: debcamp6415 at gmail.com (Debbie Campbell)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] How to use changes to libxsd?
Message-ID: <16aa9b550812110906o68ac4965yd2f5252d4a00b1e3@mail.gmail.com>

We need to do Xinclude.  It seemed straight forward to change the
appropriate files in libxsd to add a flag 'do_xinclude' and turn on the
fgXercesDoXinclude based on that flag.  It works fine with the example
programs changed to do <xi:include>. in the instance documents.  What needs
to happen to use it external of the xsd tree?  There doesn't appear to be a
libxsd that gets built, or any objs that get built which the examples are
linking with so there is something fundamental I'm missing.

Thanks!

Debbie Campbell

From boris at codesynthesis.com  Thu Dec 11 12:28:32 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] How to use changes to libxsd?
In-Reply-To: <16aa9b550812110906o68ac4965yd2f5252d4a00b1e3@mail.gmail.com>
References: <16aa9b550812110906o68ac4965yd2f5252d4a00b1e3@mail.gmail.com>
Message-ID: <20081211172832.GA30281@karelia>

Hi Debbie,

Debbie Campbell <debcamp6415@gmail.com> writes:

> We need to do Xinclude.  It seemed straight forward to change the
> appropriate files in libxsd to add a flag 'do_xinclude' and turn on the
> fgXercesDoXinclude based on that flag.  It works fine with the example
> programs changed to do <xi:include>. in the instance documents.  What needs
> to happen to use it external of the xsd tree?  There doesn't appear to be a
> libxsd that gets built, or any objs that get built which the examples are
> linking with so there is something fundamental I'm missing.

The XSD runtime (libxsd) is a header-only library so you don't
need to do anything extra. The problem, of course, arises when
a new version of XSD is released and you want to upgrade. In
this case you will need to make the change again.

The recommended way to turn XInclude support in Xerces-C++ is to
setup the XML-to-DOM stage yourself, as described in this recent
post:

http://www.codesynthesis.com/pipermail/xsd-users/2008-December/002078.html

Boris


From james.lisle2 at wellsfargo.com  Thu Dec 11 13:56:18 2008
From: james.lisle2 at wellsfargo.com (james.lisle2@wellsfargo.com)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Tree Creation with Huge XSD Document Never Completing
Message-ID: <501C9AA46CEF3741B97EBCD4DD159FF78104B3@msgswbiadsm25.wellsfargo.com>


I am new to the xsd product and am using it on Suse10.2 and Solaris 10. I am
attempting to generate a set of classes for a huge multi-file schema (15K
elements across ~200 files) which have many include statements.

The command to generate output is: xsd cxx-tree --file-per-type <schema>.
This kicks off the xsd process and it runs at 100% cpu indefinitely.  Are
there any other options I might try to complete this process?



Thanks

Jim Lisle
(O) 240.586.5726
(C) 240.674.6927


"This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you
must not use, copy, disclose, or take any action based on this message or
any information herein. If you have received this message in error, please
advise the sender immediately by reply e-mail and delete this message. Thank
you for your cooperation."


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5657 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20081211/f0a37293/smime.bin
From boris at codesynthesis.com  Thu Dec 11 14:45:09 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Tree Creation with Huge XSD Document Never Completing
In-Reply-To: <501C9AA46CEF3741B97EBCD4DD159FF78104B3@msgswbiadsm25.wellsfargo.com>
References: <501C9AA46CEF3741B97EBCD4DD159FF78104B3@msgswbiadsm25.wellsfargo.com>
Message-ID: <20081211194509.GB30537@karelia>

Hi Jim,

james.lisle2@wellsfargo.com <james.lisle2@wellsfargo.com> writes:

> I am new to the xsd product and am using it on Suse10.2 and Solaris 10. I am
> attempting to generate a set of classes for a huge multi-file schema (15K
> elements across ~200 files) which have many include statements.
> 
> The command to generate output is: xsd cxx-tree --file-per-type <schema>.
> This kicks off the xsd process and it runs at 100% cpu indefinitely.  Are
> there any other options I might try to complete this process?

This is a fairly large schema and I would expect it to take minutes 
to compile in the file-per-type mode. This mode is significantly
slower than the file-per-schema mode because the XSD compiler 
generates a separate set of source files for each type.

If you are not using the latest version of XSD (3.2.0), then you may
want to upgrade since we fixed a problem that resulted in very long
compilation times for certain schemas in the file-per-type mode.

You can also generate the XML Schema namespace into a separate file
in order to speed up code generation:

$ xsd cxx-tree --generate-xml-schema xml-schema.xsd
$ xsd cxx-tree --extern-xml-schema xml-schema.xsd --file-per-type root.xsd

I would also suggest that you include the --show-sloc option to get
an idea about the progress. Once the schema parsing and processing
is complete, you should see some information for each generated
file. 

If none of this helps (e.g., you specified --show-sloc but don't
see any output for a long time, which means schema parsing/processing
is taking very long for some reason), then, if possible, we would
like to take a look at your schema (you can send it to me directly
to keep it private). This way we can run the profiler on XSD while
it is compiling your schemas and try to find the cause of the 
slowdown.

Boris


From js.homer at yahoo.com  Fri Dec 12 08:13:11 2008
From: js.homer at yahoo.com (Homer J S)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Elements/attrs not recognized
Message-ID: <97566.79349.qm@web45601.mail.sp1.yahoo.com>

Help please anyone... I am using this piece of code for the first time:

      try
        {
          std::string str(_QueryIn); // XML in a string.
          std::istringstream iss(str);
          auto_ptr<obj_wells> h (wells (iss));
        }
      catch (const xml_schema::exception& e)
        {
          cerr << e << endl;
        }

to parse this XML string:

'<wells xmlns="http://www.witsml.org/schemas/120" version="1.2.0"><well uidWell=''><nameWell/><nameLegal/><dTimSpud/><numAPI/><statusWell/><field></field><country/><state/><county/><block/><operator/><location><latitude/><longitude/><inputType/></location><commonData><nameSource/><dTimStamp/><dTimCreation/><dTimLastChange/><itemState/><comments/></commonData></well></wells>'

But all I got back are just errors. It look like the generated parser did not recognize any of the elements/attributes, I must have missed something serious:

/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:66 error: Unknown element 'wells'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:66 error: Attribute 'xmlns' is not declared for element 'wells'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:66 error: Attribute 'version' is not declared for element 'wells'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:83 error: Unknown element 'well'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:83 error: Attribute 'uidWell' is not declared for element 'well'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:94 error: Unknown element 'nameWell'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:106 error: Unknown element 'nameLegal'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:117 error: Unknown element 'dTimSpud'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:126 error: Unknown element 'numAPI'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:139 error: Unknown element 'statusWell'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:146 error: Unknown element 'field'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:164 error: Unknown element 'country'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:172 error: Unknown element 'state'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:181 error: Unknown element 'county'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:189 error: Unknown element 'block'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:200 error: Unknown element 'operator'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:210 error: Unknown element 'location'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:221 error: Unknown element 'latitude'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:233 error: Unknown element 'longitude'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:245 error: Unknown element 'inputType'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:268 error: Unknown element 'commonData'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:281 error: Unknown element 'nameSource'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:293 error: Unknown element 'dTimStamp'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:308 error: Unknown element 'dTimCreation'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:325 error: Unknown element 'dTimLastChange'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:337 error: Unknown element 'itemState'
/home/ie/dev/cphan/rt_connect_server/witsml_str.xml:1:348 error: Unknown element 'comments'

Any suggestion to fix or debug would be appreciated.

Thanks,
JS



      
From boris at codesynthesis.com  Fri Dec 12 08:13:47 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Elements/attrs not recognized
In-Reply-To: <97566.79349.qm@web45601.mail.sp1.yahoo.com>
References: <97566.79349.qm@web45601.mail.sp1.yahoo.com>
Message-ID: <20081212131347.GE2635@karelia>

Hi,

Homer J S <js.homer@yahoo.com> writes:

>       try
>         {
>           std::string str(_QueryIn); // XML in a string.
>           std::istringstream iss(str);
>           auto_ptr<obj_wells> h (wells (iss));
>         }
>       catch (const xml_schema::exception& e)
>         {
>           cerr << e << endl;
>         }
> 
> to parse this XML string:
> 
> '<wells xmlns="http://www.witsml.org/schemas/120" version="1.2.0">...
> 
> But all I got back are just errors. It look like the generated parser 
> did not recognize any of the elements/attributes, I must have missed
> something serious:

No, not too serious ;-). See Q2.1 in the C++/Tree Mapping FAQ:

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


Boris


From js.homer at yahoo.com  Fri Dec 12 08:57:37 2008
From: js.homer at yahoo.com (Homer J S)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Elements/attrs not recognized
Message-ID: <468092.40090.qm@web45604.mail.sp1.yahoo.com>

Thank you so much Boris. I hope you wont mind I ask another question please. The input string I parsed 

'<wells xmlns="http://www.witsml.org/schemas/120"
version="1.2.0"><well
uidWell=''><nameWell/><nameLegal/><dTimSpud/><numAPI/><statusWell/><field></field><country/><state/><county/><block/><operator/><location><latitude/><longitude/><inputType/></location><commonData><nameSource/><dTimStamp/><dTimCreation/><dTimLastChange/><itemState/><comments/></commonData></well></wells>'

contains element <statusWell/> which is an enumeration defined below:

    <xsd:simpleType name="WellStatus">
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="Abandoned"/>
            <xsd:enumeration value="Active"/>
            <xsd:enumeration value="Drilling"/>
            <xsd:enumeration value="DrillingSuspended"/>
            <xsd:enumeration value="Permitted"/>
            <xsd:enumeration value="PartiallyPlugged"/>
            <xsd:enumeration value="PluggedAndAbandoned"/>
            <xsd:enumeration value="Proposed"/>
            <xsd:enumeration value="Plugged"/>
            <xsd:enumeration value="StatusUnknown"/>
            <xsd:enumeration value="Suspended"/>
            <xsd:enumeration value="TemporarilyAbandoned"/>
        </xsd:restriction>
    </xsd:simpleType>

The
problem is that the parser raised an error because the input string
does not explicitly specify a value for element statusWell. Is there a
way to bypassing this problem please.

Thanks
JS




________________________________
From: Boris Kolpackov <boris@codesynthesis.com>
To: Homer J S <js.homer@yahoo.com>
Cc: xsd-users@codesynthesis.com
Sent: Friday, December 12, 2008 7:13:47 AM
Subject: Re: [xsd-users] Elements/attrs not recognized

Hi,

Homer J S <js.homer@yahoo.com> writes:

>       try
>         {
>           std::string str(_QueryIn); // XML in a string.
>           std::istringstream iss(str);
>           auto_ptr<obj_wells> h (wells (iss));
>         }
>       catch (const xml_schema::exception& e)
>         {
>           cerr << e << endl;
>         }
> 
> to parse this XML string:
> 
> '<wells xmlns="http://www.witsml.org/schemas/120" version="1.2.0">...
> 
> But all I got back are just errors. It look like the generated parser 
> did not recognize any of the elements/attributes, I must have missed
> something serious:

No, not too serious ;-). See Q2.1 in the C++/Tree Mapping FAQ:

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


Boris



      
From boris at codesynthesis.com  Fri Dec 12 10:54:12 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] Elements/attrs not recognized
In-Reply-To: <468092.40090.qm@web45604.mail.sp1.yahoo.com>
References: <468092.40090.qm@web45604.mail.sp1.yahoo.com>
Message-ID: <20081212155412.GA8862@karelia>

Hi,

Homer J S <js.homer@yahoo.com> writes:

> The input string I parsed 
> 
> [...]
> 
> contains element <statusWell/> which is an enumeration defined below:
> 
>     <xsd:simpleType name="WellStatus">
>         <xsd:restriction base="xsd:string">
>             <xsd:enumeration value="Abandoned"/>
>             <xsd:enumeration value="Active"/>
> [...]
>         </xsd:restriction>
>     </xsd:simpleType>
> 
> The problem is that the parser raised an error because the input string
> does not explicitly specify a value for element statusWell. Is there a
> way to bypassing this problem please.

Your XML document is not valid per your schema. There are generally
two ways to resolve this:

1. Fix your XML document to be valid.

2. Fix your schema to allow for the invalid construct. In your case
   that would mean, for example, adding <xsd:enumeration value=""/>
   to the WellStatus.

3. Disable XML Schema validation in the underlying XML parser and
   customize the generated code (the WellStatus class in your case)
   to take care of the invalid parts in your XML documents.

For more information on type customization see the C++/Tree Mapping
Customization Guide[1] as well as the examples in the 
examples/cxx/tree/custom/ directory. In your case you would want
to customize the parsing constructors to detect the empty value
situation.

[1] http://wiki.codesynthesis.com/Tree/Customization_guide

Boris


From a.omrani at gmail.com  Sun Dec 28 06:16:13 2008
From: a.omrani at gmail.com (Azadeh Omrani)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] handling auto_ptr?
Message-ID: <183a50e60812280316x2c765d4bi15df648e60489de2@mail.gmail.com>

Hi,

I have the auto_ptr pointer pointing to the memory which has been filled by
parsing an xml document. This is done in a method of a class.

class A
{
    auto_ptr<b::B> p;
public:
   void parseData(string); //fills the memory pointed by p using xsd.

   void?? getParsedData(auto_ptr<b::B>??);

 A();
~A();
}

void main()
{
A * a =new A();
a->parseData("inst.xml");

//How can I have  the parsed data here without nullifying the private
parameter p? (coz I will need p locally later)

//auto_ptr<b::B> ap;
//a->getParsedData(ap); ?? This way (ap=p;) the member p will be destroyed

}

Actually I want to know how to make a whole copy of the memory pointed by an
auto_ptr without loosing the source and without double parsing.

Thank you
Azadeh

From boris at codesynthesis.com  Sun Dec 28 06:58:17 2008
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:07 2009
Subject: [xsd-users] handling auto_ptr?
In-Reply-To: <183a50e60812280316x2c765d4bi15df648e60489de2@mail.gmail.com>
References: <183a50e60812280316x2c765d4bi15df648e60489de2@mail.gmail.com>
Message-ID: <20081228115817.GA2559@karelia>

Hi Azadeh,

Azadeh Omrani <a.omrani@gmail.com> writes:

> class A
> {
>   auto_ptr<b::B> p;
> public:
>   void parseData(string); //fills the memory pointed by p using xsd.
> 
>   void?? getParsedData(auto_ptr<b::B>??);
> 
>   A();
>   ~A();
> }
> 
> void main()
> {
>   A * a =new A();
>   a->parseData("inst.xml");
> 
>   // How can I have  the parsed data here without nullifying the private
>   // parameter p? (coz I will need p locally later)

Note that this is not a question about XSD but rather about std::auto_ptr
and it is answered in your favorite C++ book.

It is not possible to have two instances of std::auto_ptr pointing to the
same object. So what you can do is return a normal pointer or reference,
for example:

b::B& A::getParsedData()
{
  return *p;
}

This way, however, you need to make sure that the 'a' instance is around
for as long as you have pointers/references to the object model.

Alternatively, you can use a smart pointer that support the sharing
semantics, e.g., Boost shared_ptr:

class A
{
  shared_ptr<b::B> p;

public:
  void parseData (string s)
  {
    auto_ptr<b::B> tmp = ... // parse s
    p = shared_ptr<b::B> (tmp.release ());
  }

  shared_ptr<b::B> getParsedData ()
  {
    return p;
  }
};

> Actually I want to know how to make a whole copy of the memory 
> pointed by an auto_ptr without loosing the source and without 
> double parsing.

You can use _clone() for this:

auto_ptr<b::B> A::getParsedData()
{
  return auto_ptr<b::B> (p->_clone ());
}

Boris