From thakanoduncu at gmail.com Tue Mar 24 04:42:43 2020 From: thakanoduncu at gmail.com (Tolga Hakan ODUNCU) Date: Tue Mar 24 10:39:45 2020 Subject: [xsd-users] Cropped data problem due to enforced upcasting in C++. Message-ID: Dear xsd-users, Hello, I need some help about an issue I couldn't succeed myself. I have an enforced upcasting problem with my auto-generated C++ codes. This is a part of the XSD schema I used to generate C++ codes to run on my Linux Ubuntu VM. // Other X1RequestMessage elements .... // Other ReportTaskIssueRequest elements .... // Other referenced complexTypes and simpleTypes ..... Since this schema includes base and derived types, I generated the C++ 11 codes with -generate-polymorphic parameter as proposed on Command Line Manuel. My RequestContainer class is generated as follow; class RequestContainer: public ::xml_schema::type { public: // x1RequestMessage // typedef ::X1RequestMessage x1RequestMessage_type; typedef ::xsd::cxx::tree::sequence< x1RequestMessage_type > x1RequestMessage_sequence; typedef x1RequestMessage_sequence::iterator x1RequestMessage_iterator; typedef x1RequestMessage_sequence::const_iterator x1RequestMessage_const_iterator; typedef ::xsd::cxx::tree::traits< x1RequestMessage_type, char > x1RequestMessage_traits; const x1RequestMessage_sequence& x1RequestMessage () const; x1RequestMessage_sequence& x1RequestMessage (); void x1RequestMessage (const x1RequestMessage_sequence& s); // Constructors. // ........ ... } Referring manual, I see that I can only add an item to my RequestContainer class via "x1RequestMessage_sequence", a sequence of X1RequestMessage. What I need is a generic RequestContainer class that's capable of storing any type of data derived from X1RequestMessage class. Because when I serialize my RequestContainer data, for instance, it should also have properties of ReportTaskIssueRequest class together with properties of X1RequestMessage class and it should look like that; admfID //... X1RequestMessage properties 29f28e1c-f230-486a-a860-f5a784ab9172 // .. ReportTaskIssueRequest properties However, when I push back my ReportTaskIssueRequest object to x1RequestMessage_sequence directly or with _clone() function, my object is upcasted to X1RequestMessage and properties belonging to ReportTaskIssueRequest are cropped and xsi:type attribute is invisible. Then it looks like that admfID //... X1RequestMessage properties I tried many things, but unfortunately couldn't find a proper solution. On user manual, section 2.11 states that in a collection including base and derived types, items can be downcasted with dynamic_cast operation to get derived type object, but there is not any information about upcasting. My XSD schemes are produced by an official organization, ETSI. I don't see what I'm missing. Could be there an issue with XSD files, or do I skip a required command line parameter when I'm generating the codes. Thanks already for any kind of support. Kind Regards, Tolga Hakan Oduncu From boris at codesynthesis.com Tue Mar 24 10:43:20 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 24 10:51:45 2020 Subject: [xsd-users] Cropped data problem due to enforced upcasting in C++. In-Reply-To: References: Message-ID: Tolga Hakan ODUNCU writes: > Since this schema includes base and derived types, I generated the C++ 11 > codes with -generate-polymorphic parameter as proposed on Command Line > Manuel. Have you also specified --polymorphic-type RequestContainer or, alternatively, --polymorphic-type-all? > However, when I push back my ReportTaskIssueRequest object to > x1RequestMessage_sequence directly or with _clone() function, my object is > upcasted to X1RequestMessage and properties belonging to > ReportTaskIssueRequest are cropped and xsi:type attribute is invisible. You could verify that the object you have pushed retains its dynamic type with dynamic_cast: x.x1RequestMessage ().push_back (...); dynamic_cast (x.x1RequestMessage ().back ()); If this works as expected, then it's definitely something with the configuration of the generated code (for example, missing --polymorphic-type*). From thakanoduncu at gmail.com Thu Mar 26 02:36:00 2020 From: thakanoduncu at gmail.com (Tolga Hakan ODUNCU) Date: Thu Mar 26 08:15:13 2020 Subject: [xsd-users] Cropped data problem due to enforced upcasting in C++. In-Reply-To: References: Message-ID: Hello Boris, I tried some generation parameters for required class as you proposed. When I generated with --polymorphic-type-all, generated codes did not compile but declaring each required class seperately worked. Also verified by downcasting with dynamic_cast. Finally, I could succeed to serialize my data as I want to do. Thanks a lot for your help. Sincerely On Tue, Mar 24, 2020 at 5:43 PM Boris Kolpackov wrote: > Tolga Hakan ODUNCU writes: > > > Since this schema includes base and derived types, I generated the C++ 11 > > codes with -generate-polymorphic parameter as proposed on Command Line > > Manuel. > > Have you also specified --polymorphic-type RequestContainer or, > alternatively, --polymorphic-type-all? > > > > However, when I push back my ReportTaskIssueRequest object to > > x1RequestMessage_sequence directly or with _clone() function, my object > is > > upcasted to X1RequestMessage and properties belonging to > > ReportTaskIssueRequest are cropped and xsi:type attribute is invisible. > > You could verify that the object you have pushed retains its dynamic > type with dynamic_cast: > > x.x1RequestMessage ().push_back (...); > dynamic_cast (x.x1RequestMessage ().back ()); > > If this works as expected, then it's definitely something with the > configuration of the generated code (for example, missing > --polymorphic-type*). > From sawhite at ara.com Thu Mar 26 13:32:08 2020 From: sawhite at ara.com (Steven White) Date: Thu Mar 26 13:40:54 2020 Subject: [xsd-users] MacOS 10.15 Catalina (x64) Builds Message-ID: Would it be possible to post a 64bit build for the osX/macOS platform. I was updating the build machine for our mac variant and suddenly became aware that 10.15 dropped support for 32bit executables. I'm planning on building my own variant next week, but updating the BioGears build documentation would be vastly easier if and official release was made. From thakanoduncu at gmail.com Fri Mar 27 06:08:29 2020 From: thakanoduncu at gmail.com (Tolga Hakan ODUNCU) Date: Fri Mar 27 07:35:19 2020 Subject: [xsd-users] Parsing XML string to tree object issue Message-ID: Dear xsd group members, Hello, I have a few questions about parsing xml string data. With your support to my previous mail I managed to serialize my tree objects to xml string, however I cannot make reverse now. According to the user manual, a simple code sample is proposed for parsing xml string data to tree object (Section 3.5). { std::string str ("..."); // Some XML fragment. std::istringstream iss (str); auto_ptr r (name (iss)); } When I want to use this sample with my own types as follows, { std::istringstream iss (requestContainerStr); // requestContainerStr is a string that has valid xml format. std::unique_ptr xsd_RequestContainer (Etsi103221::X1Request (iss)); } I get the exception "instance document parsing failed" My question is that, are generated codes with cxx-tree command sufficient for this parsing operation, or do I also need to generate parser codes with cxx-parser command. The user manual ( https://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/) does not have any statement about generating parser. I noticed the cxx-parser command on the Compiler Command Line Manual ( https://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml) Thanks for your support. Kind Regards, Tolga Hakan Oduncu From boris at codesynthesis.com Fri Mar 27 07:34:53 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 27 07:43:28 2020 Subject: [xsd-users] MacOS 10.15 Catalina (x64) Builds In-Reply-To: References: Message-ID: Steven White writes: > Would it be possible to post a 64bit build for the osX/macOS platform. I > was updating the build machine for our mac variant and suddenly became aware > that 10.15 dropped support for 32bit executables. I'm planning on building > my own variant next week, but updating the BioGears build documentation > would be vastly easier if and official release was made. We are working on getting all our tools easily buildable on every platform from source packages but things are moving slower than hoped and XSD is still probably at least several months out. I think in the meantime the easiest would be to build the XSD compiler from source using the old method, which shouldn't be too onerous on Mac OS (unlike, say, Windows). Let me know if this will work and I will send you the instructions. From sawhite at ara.com Fri Mar 27 09:49:01 2020 From: sawhite at ara.com (Steven White) Date: Fri Mar 27 09:57:37 2020 Subject: [xsd-users] MacOS 10.15 Catalina (x64) Builds In-Reply-To: References: Message-ID: I'm going to give build instructions a try next week. Currently, locked down between two deadlines when I noticed the issue. I'm super excited about a new build system so that's worth the wait. I'll report back if I have any trouble once I can sit down and pull all the requirements down and start a build. -----Original Message----- From: Boris Kolpackov Sent: Friday, March 27, 2020 07:35 To: Steven White Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] MacOS 10.15 Catalina (x64) Builds Steven White writes: > Would it be possible to post a 64bit build for the osX/macOS platform. > I was updating the build machine for our mac variant and suddenly > became aware that 10.15 dropped support for 32bit executables. I'm > planning on building my own variant next week, but updating the > BioGears build documentation would be vastly easier if and official release was made. We are working on getting all our tools easily buildable on every platform from source packages but things are moving slower than hoped and XSD is still probably at least several months out. I think in the meantime the easiest would be to build the XSD compiler from source using the old method, which shouldn't be too onerous on Mac OS (unlike, say, Windows). Let me know if this will work and I will send you the instructions. From boris at codesynthesis.com Mon Mar 30 09:47:21 2020 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 30 09:56:08 2020 Subject: [xsd-users] Parsing XML string to tree object issue In-Reply-To: References: Message-ID: Tolga Hakan ODUNCU writes: > std::istringstream iss (requestContainerStr); // requestContainerStr is a string that has valid xml format. > std::unique_ptr xsd_RequestContainer (Etsi103221::X1Request (iss)); > > I get the exception "instance document parsing failed" Print the exception to get more information, as described in Section 2.2, "Error Handling": https://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.2 It most likely has to do with XML Schema validation; see the relevant questions in the FAQ: http://wiki.codesynthesis.com/Tree/FAQ > My question is that, are generated codes with cxx-tree command sufficient > for this parsing operation [...] Yes, it should be.