From boris at codesynthesis.com Wed Oct 1 16:09:29 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Re: Spec file for XSD.. In-Reply-To: <7989E8376B575A48988B91440219DA6001C6A345@EXCHANGE2003.NADA.org> References: <7989E8376B575A48988B91440219DA6001C6A345@EXCHANGE2003.NADA.org> Message-ID: <20081001200929.GA21793@karelia> Hi Bill, I've CC'ed the xsd-users mailing list to my reply in case there is someone who uses XSD on Mandriva and can provide us with some information on this. Fitzpatrick, Bill writes: > I noticed you have an RPM package for redhat. Do you have on that is > compatible with Mandriva. I am not an RPM expert so I am not sure if there is anything that precludes using the published .rpm package on Mandriva. We definitely didn't do anything special to limit it to RadHat. Have you tried installing it on Mandriva? > Or if you don't can you publish the src.rpm files? The spec file that we use is very ad-hoc and is tied to the way we build things internally. You will need to build XSD and all its prerequisites from scratch. Let me know if you are interested and I will send you the file along with the instructions. Boris From BFITZPATRICK at NADA.org Wed Oct 1 16:18:25 2008 From: BFITZPATRICK at NADA.org (Fitzpatrick, Bill) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] RE: Spec file for XSD.. In-Reply-To: <20081001200929.GA21793@karelia> References: <7989E8376B575A48988B91440219DA6001C6A345@EXCHANGE2003.NADA.org> <20081001200929.GA21793@karelia> Message-ID: <7989E8376B575A48988B91440219DA6001C6A349@EXCHANGE2003.NADA.org> If you send me the spec file I can 'fix' it to make it work. If I make any changes I'll send it back to you. A good spec file will not only build the rpm but check for prerequisites as well. Bill -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, October 01, 2008 4:09 PM To: Fitzpatrick, Bill Cc: xsd-users@codesynthesis.com Subject: Re: Spec file for XSD.. Hi Bill, I've CC'ed the xsd-users mailing list to my reply in case there is someone who uses XSD on Mandriva and can provide us with some information on this. Fitzpatrick, Bill writes: > I noticed you have an RPM package for redhat. Do you have on that is > compatible with Mandriva. I am not an RPM expert so I am not sure if there is anything that precludes using the published .rpm package on Mandriva. We definitely didn't do anything special to limit it to RadHat. Have you tried installing it on Mandriva? > Or if you don't can you publish the src.rpm files? The spec file that we use is very ad-hoc and is tied to the way we build things internally. You will need to build XSD and all its prerequisites from scratch. Let me know if you are interested and I will send you the file along with the instructions. Boris From boris at codesynthesis.com Wed Oct 1 17:08:54 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Re: Spec file for XSD.. In-Reply-To: <7989E8376B575A48988B91440219DA6001C6A349@EXCHANGE2003.NADA.org> References: <7989E8376B575A48988B91440219DA6001C6A345@EXCHANGE2003.NADA.org> <20081001200929.GA21793@karelia> <7989E8376B575A48988B91440219DA6001C6A349@EXCHANGE2003.NADA.org> Message-ID: <20081001210854.GB21793@karelia> Hi Bill, Fitzpatrick, Bill writes: > If you send me the spec file I can 'fix' it to make it work. The .rpm spec file is attached. Here are a few note on how it works right now: 1. The spec is designed to link libstdc++ statically. 2. It installs some things from ../../../work/xsd/dist/unix/xsd. This is a hard coded path on out build box that contains example README files as well as the build systems. You can find these files in any precompiled binary package, e.g., xsd-3.2.0-i686-linux-gnu.tar.bz2 We use the spec file as follows: 1. Build all the prerequisites except XSD. Basically follow the build instructions for UNIX until XSD: http://www.codesynthesis.com/projects/xsd/extras/build-unix.xhtml 2. Then run: $ export CXX=g++ $ rpmbuild -ba xsd.spec If you would like to automate the build process, including configuration and building of prerequisites then you can take a look at how Raphael Bossek did this for the Debian package. He basically created and saved a configuration where all the prerequisites are installed. His rules script (Debian's counterpart of the spec file) would then unpack each prerequisite, copy the configuration, build, and install. Boris -------------- next part -------------- Summary: XML Schema to C++ data binding compiler Name: xsd Version: 3.2.0 Release: 1 License: GPL version 2 + exceptions; http://www.codesynthesis.com/projects/xsd/ Group: Development/Tools Source: http://www.codesynthesis.com/download/xsd/3.2/%{name}-%{version}.tar.bz2 Prefix: %{_prefix} Buildroot: %{_tmppath}/%{name}-root AutoReqProv: no %description CodeSynthesis XSD is an XML Schema to C++ data binding compiler. Provided with an XML instance specification (XML Schema), it generates C++ classes that represent the given vocabulary as well as parsing and serialization code. %prep %setup -q %build %ifarch x86_64 HOST_CPU=x86_64; export HOST_CPU %endif %ifarch i686 HOST_CPU=i686; export HOST_CPU %endif /bin/sh -c "if test -z "\$HOST_CPU" ; then echo error HOST_CPU not set && exit 1; fi" /bin/sh -c "if test -z "\$CXX" ; then echo error CXX not set && exit 1; fi" /bin/sh -c "ln -s `\$CXX --print-file-name=libstdc++.a` ./xsd/libstdc++.a" echo "host cpu $HOST_CPU" make -C xsd cxx_ld_options="-L. -static-libgcc" verbose=1 rm -f ./xsd/libstdc++.a # We don't want the binaries to be stripped. # %ifarch x86_64 %define __os_install_post /usr/lib/rpm/brp-compress %endif %install %ifarch x86_64 HOST_CPU=x86_64; export HOST_CPU %endif %ifarch i686 HOST_CPU=i686; export HOST_CPU %endif rm -rf ${RPM_BUILD_ROOT} echo "host cpu $HOST_CPU" make install \ install_bin_dir=$RPM_BUILD_ROOT%{_bindir} \ install_inc_dir=$RPM_BUILD_ROOT%{_includedir} \ install_lib_dir=$RPM_BUILD_ROOT%{_libdir} \ install_data_dir=$RPM_BUILD_ROOT%{_datadir} \ install_doc_dir=$RPM_BUILD_ROOT%{_docdir} \ install_man_dir=$RPM_BUILD_ROOT%{_mandir} \ install_info_dir=$RPM_BUILD_ROOT%{_infodir} install -m 644 ../../../work/xsd/dist/unix/xsd/README $RPM_BUILD_ROOT%{_docdir}/xsd cp -rL ../../../work/xsd/dist/unix/xsd/examples $RPM_BUILD_ROOT%{_docdir}/xsd %clean rm -rf ${RPM_BUILD_ROOT} %post %preun %files %defattr(-,root,root) %{_bindir}/xsd %{_includedir}/xsd %{_docdir}/xsd %{_docdir}/libxsd %ifarch x86_64 %{_mandir}/man1/xsd.1.gz %else %{_mandir}/man1/xsd.1 %endif %changelog * Tue Sep 30 2008 Boris Kolpackov - new upstream release * Wed Feb 06 2008 Boris Kolpackov - new upstream release * Tue Jul 31 2007 Boris Kolpackov - new upstream release * Tue Jan 23 2007 Boris Kolpackov - new upstream release * Mon Sep 18 2006 Boris Kolpackov - new upstream release * Mon Jul 10 2006 Boris Kolpackov - new upstream release * Mon May 01 2006 Boris Kolpackov - new upstream release * Mon Apr 18 2006 Boris Kolpackov - new upstream release * Sun Mar 13 2006 Boris Kolpackov - new upstream release * Sun Feb 05 2006 Boris Kolpackov - new upstream release * Mon Jan 16 2006 Boris Kolpackov - new upstream release * Mon Dec 05 2005 Boris Kolpackov - new upstream release * Tue Nov 08 2005 Boris Kolpackov - new upstream release * Mon Oct 20 2005 Boris Kolpackov - new upstream release * Mon Oct 03 2005 Boris Kolpackov - new upstream release * Fri Sep 16 2005 Boris Kolpackov - new upstream release * Thu Sep 01 2005 Boris Kolpackov - new upstream release * Thu Aug 25 2005 Boris Kolpackov - new upstream release * Sat Aug 06 2005 Boris Kolpackov - new upstream release * Wed Jul 20 2005 Boris Kolpackov - spec file written for xsd From boris at codesynthesis.com Wed Oct 1 17:16:50 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Re: Spec file for XSD.. In-Reply-To: <20081001210854.GB21793@karelia> References: <7989E8376B575A48988B91440219DA6001C6A345@EXCHANGE2003.NADA.org> <20081001200929.GA21793@karelia> <7989E8376B575A48988B91440219DA6001C6A349@EXCHANGE2003.NADA.org> <20081001210854.GB21793@karelia> Message-ID: <20081001211650.GC21793@karelia> Hi Bill, Boris Kolpackov writes: > take a look at how Raphael Bossek did this for the Debian package Sorry, forgot to mention the link: http://packages.qa.debian.org/x/xsd.html The .diff file is the one containing all the interesting parts. It is a patch against the .orig file. Boris From Raymond.Rizzuto at sig.com Wed Oct 1 17:11:07 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] (no subject) Message-ID: I'm getting an exception on parsing a message using cxx-tree. The code I have is: try { // parse the message back in and print it xml_schema::properties props; props.schema_location("http://sig.com/sdmp/messages", "SDMP.xsd"); std::auto_ptr m1 = parse_message(sdmpMessage, xml_schema::flags::dont_initialize, props); . . . delete m1; } catch (const xml_schema::exception& e) { std::cerr << e << endl; } The error message displayed via the catch block is: ":11:196 error: This type of attribute cannot have an empty value" Is there any way to get more detail from the exception, such as the name of the attribute? I figured that :11:196 was the line and column, and was able to figure what the issue was, but the name would have been quicker. Ray ________________________________ Ray Rizzuto raymond.rizzuto@sig.com Susquehanna International Group (610)747-2336 (W) (215)776-3780 (C) ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From boris at codesynthesis.com Wed Oct 1 17:29:54 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] attribute name in error message In-Reply-To: References: Message-ID: <20081001212954.GD21793@karelia> Hi Ray, Rizzuto, Raymond writes: > std::auto_ptr m1 = parse_message(sdmpMessage, xml_schema::flags::dont_initialize, props); You may want to provide the document id (name) for diagnostics: std::auto_ptr m1 = parse_message( sdmpMessage, "message.xml" xml_schema::flags::dont_initialize, props); Then the error will be: message.xml:11:196 error: This type of attribute cannot have an empty value > The error message displayed via the catch block is: ":11:196 error: This > type of attribute cannot have an empty value" Is there any way to get > more detail from the exception, such as the name of the attribute? Not at the moment. This error message is propagated from the Xerces-C++ validator so we will need to address it there. I've added it to the TODO list and hopefully we will be able to fix this for the next release of Xerces-C++. Boris From Raymond.Rizzuto at sig.com Thu Oct 2 09:16:29 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] attribute name in error message In-Reply-To: <20081001212954.GD21793@karelia> References: <20081001212954.GD21793@karelia> Message-ID: Boris, Thanks for the suggestion. I don't really have a document since I'm parsing an in-memory string created from serializing an XML object. But I may be able to pass a string describing with the message name to help with diagnosing the issue. I appreciate your adding a TODO item to have Xerces-C++ provide that information. I think that would be very helpful, in general. Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, October 01, 2008 5:30 PM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] attribute name in error message Hi Ray, Rizzuto, Raymond writes: > std::auto_ptr m1 = parse_message(sdmpMessage, xml_schema::flags::dont_initialize, props); You may want to provide the document id (name) for diagnostics: std::auto_ptr m1 = parse_message( sdmpMessage, "message.xml" xml_schema::flags::dont_initialize, props); Then the error will be: message.xml:11:196 error: This type of attribute cannot have an empty value > The error message displayed via the catch block is: ":11:196 error: This > type of attribute cannot have an empty value" Is there any way to get > more detail from the exception, such as the name of the attribute? Not at the moment. This error message is propagated from the Xerces-C++ validator so we will need to address it there. I've added it to the TODO list and hopefully we will be able to fix this for the next release of Xerces-C++. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From gleonid at yahoo.com Sun Oct 5 12:30:32 2008 From: gleonid at yahoo.com (Leonid Gershanovich) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] XSD C++/Parser and enumerations Message-ID: <994108.61630.qm@web90401.mail.mud.yahoo.com> Is there any particular reason why xsd generator in "C++/Parser" mode does not creates C++ enums for .. xsd construct? I have noticed that C++ enums along with corresponding conversion functions are being generated?in C++/Tree?mode, which indicates that xsd generator already has capability to detect this SOM element. In my opinion it?might benefit developers to have "enum" construct and stringToEnum conversion functions generated automatically, even if all other generated components remains the same. Having enum generated in combinations with "type map" functionality will give developer a choice to either utilize or ignore c++ enums. Does this make sense? ?Leonid Gershanovich From boris at codesynthesis.com Mon Oct 6 04:06:40 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] XSD C++/Parser and enumerations In-Reply-To: <994108.61630.qm@web90401.mail.mud.yahoo.com> References: <994108.61630.qm@web90401.mail.mud.yahoo.com> Message-ID: <20081006080640.GB16034@karelia> Hi Leonid, Leonid Gershanovich writes: > Is there any particular reason why xsd generator in "C++/Parser" mode > does not creates C++ enums for > > > > .. > > > xsd construct? I agree this sounds like a natural thing to do but conceptually the C++/Parser mapping does not produce "data" types that corresponds to the XML Schema types. Instead it produces parser skeleton types and custom "data" types, if any, are provided by the application. We cannot assume that everyone wants enums returned for types like above. Some people might need a string. > In my opinion it?might benefit developers to have "enum" construct > and stringToEnum conversion functions generated automatically, even > if all other generated components remains the same. That actually might be a good idea. That is, there could be an option that triggers generation of a utility enum and a conversion function but the parser return types stay the same. There won't be any way to specify this enum value in the type map but I think this shouldn't be a problem (in most cases application enums and generated enums can simply be cast back and forth). I've added this to the TODO list. Thanks for the suggestion! Boris From jeffrey.yu at panpacificinvestment.com Mon Oct 6 08:46:26 2008 From: jeffrey.yu at panpacificinvestment.com (Jeffrey Yu) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] different behavior by xsd 3.0 and 3.2 Message-ID: <000301c927b1$8bc46b50$a34d41f0$%yu@panpacificinvestment.com> Hi, I just gave the newly release 3.2 a try. It appears the xsd.exe of 3.2 treats the "string" differently. Attached is the xsd file, and I use following command to produce the data binding object: xsd cxx-tree -root-element TSInput -generate-serialization TSInput.xsd The problem is with the attribute named "value_type" of YCInput. In the xsd file, the type is "string". It becomes "decimal" in TSInput.hxx. There is no problem with 3.0. Can someone share insights on this? Maybe bug, maybe I've missed some new requirements introduced in 3.2. thx -------------- next part -------------- A non-text attachment was scrubbed... Name: TSInput.xsd Type: application/xml Size: 3141 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20081006/9c09eac1/TSInput.xml From boris at codesynthesis.com Mon Oct 6 09:28:54 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] different behavior by xsd 3.0 and 3.2 In-Reply-To: <000301c927b1$8bc46b50$a34d41f0$%yu@panpacificinvestment.com> References: <000301c927b1$8bc46b50$a34d41f0$%yu@panpacificinvestment.com> Message-ID: <20081006132854.GA19415@karelia> Hi Jeffrey, Jeffrey Yu writes: > The problem is with the attribute named "value_type" of YCInput. In the > xsd file, the type is "string". It becomes "decimal" in TSInput.hxx. What happened is that the duplicate name escaping algorithm has changed since 3.0.0. Here is what happens in more detail: your have the following two attributes in YCInput: In XSD 3.0.0 they were translated into these declarations: // value // typedef ::xml_schema::decimal value_type1; const value_type1& value () const; // value_type // typedef ::xml_schema::string value_type_type; const value_type_type& value_type () const; As you can see the typedef name for the 'value' attribute conflicted with the name of the 'value_type' attribute and was escaped to value_type1. Now here is what's generated by XSD 3.2.0: // value // typedef ::xml_schema::decimal value_type; const value_type& value () const; // value_type // typedef ::xml_schema::string value_type_type; const value_type_type& value_type1 () const; As you can see, the algorithm has changed slightly and now the second occurrence of value_type is escaped. This change was made to make the outcome of type escaping more predictable. The original logic was trying to be clever in some simple cases like the above but was not very consistent in some more complicated situations. The root of the problem here is that the type names and function names use the same naming conventions. Since 3.1.0 you can select naming conventions for types and functions from a list of predefined, widely-used conventions (you can also fine-tune this to provide your custom convention). We can for example switch to the "upper camel case" type naming to resolve the above problem: $ xsd cxx-tree --type-naming ucc TSInput.xsd This will result in the following definitions: // value // typedef ::xml_schema::Decimal ValueType; const ValueType& value () const; // value_type // typedef ::xml_schema::String Value_typeType; const Value_typeType& value_type () const; For more information on naming conventions see the NAMING CONVENTION section in the XSD Compiler Command Line Manual: http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml Boris From jeffrey.yu at panpacificinvestment.com Mon Oct 6 10:59:15 2008 From: jeffrey.yu at panpacificinvestment.com (Jeffrey Yu) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] different behavior by xsd 3.0 and 3.2 In-Reply-To: <20081006132854.GA19415@karelia> References: <000301c927b1$8bc46b50$a34d41f0$%yu@panpacificinvestment.com> <20081006132854.GA19415@karelia> Message-ID: <000001c927c4$19e9b630$4dbd2290$%yu@panpacificinvestment.com> Boris, Yes, it is caused by the use of "value_type" in my xsd file. It seems the "type" is a popular word in the world of programming. Do you think it is possible to deploy a better name mangling mechanism in xsd compiler so variable names can be unique and don't collide With the user-defined variables? After making the changes, I run into a different problem: The use of TSInput.xsd are in two different projects binding under one solution, I am talking in Visual Studio 2005. The first project is served as a static library while the 2nd one is the front end. Both projects call xsd.exe to produce the data binding objects as their own pre-build event. Here is the problem: The preprocessor put at top of the .hxx are different. My guess is the location of the xsd is used as part of the preprocessor. If the xsd is in the default location, the name of the file is used to construct the preprocessor, TSINPUT_HXX for instance. However, when the project is in a different location other than where xsd is, the relative path is placed in front of the file name. As such, TSInput would be wrapped under two different preprocessors. In my case here, the front end references to the header file. It comes to realize TSInput has been created. In short, it is the preprocessors placed in top of the .hxx have the different names caused the problem. Jeff -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, October 06, 2008 9:29 AM To: Jeffrey Yu Cc: XSD-users Subject: Re: [xsd-users] different behavior by xsd 3.0 and 3.2 Hi Jeffrey, Jeffrey Yu writes: > The problem is with the attribute named "value_type" of YCInput. In the > xsd file, the type is "string". It becomes "decimal" in TSInput.hxx. What happened is that the duplicate name escaping algorithm has changed since 3.0.0. Here is what happens in more detail: your have the following two attributes in YCInput: In XSD 3.0.0 they were translated into these declarations: // value // typedef ::xml_schema::decimal value_type1; const value_type1& value () const; // value_type // typedef ::xml_schema::string value_type_type; const value_type_type& value_type () const; As you can see the typedef name for the 'value' attribute conflicted with the name of the 'value_type' attribute and was escaped to value_type1. Now here is what's generated by XSD 3.2.0: // value // typedef ::xml_schema::decimal value_type; const value_type& value () const; // value_type // typedef ::xml_schema::string value_type_type; const value_type_type& value_type1 () const; As you can see, the algorithm has changed slightly and now the second occurrence of value_type is escaped. This change was made to make the outcome of type escaping more predictable. The original logic was trying to be clever in some simple cases like the above but was not very consistent in some more complicated situations. The root of the problem here is that the type names and function names use the same naming conventions. Since 3.1.0 you can select naming conventions for types and functions from a list of predefined, widely-used conventions (you can also fine-tune this to provide your custom convention). We can for example switch to the "upper camel case" type naming to resolve the above problem: $ xsd cxx-tree --type-naming ucc TSInput.xsd This will result in the following definitions: // value // typedef ::xml_schema::Decimal ValueType; const ValueType& value () const; // value_type // typedef ::xml_schema::String Value_typeType; const Value_typeType& value_type () const; For more information on naming conventions see the NAMING CONVENTION section in the XSD Compiler Command Line Manual: http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml Boris From boris at codesynthesis.com Mon Oct 6 12:58:51 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] different behavior by xsd 3.0 and 3.2 In-Reply-To: <000001c927c4$19e9b630$4dbd2290$%yu@panpacificinvestment.com> References: <000301c927b1$8bc46b50$a34d41f0$%yu@panpacificinvestment.com> <20081006132854.GA19415@karelia> <000001c927c4$19e9b630$4dbd2290$%yu@panpacificinvestment.com> Message-ID: <20081006165851.GA20312@karelia> Hi Jeffrey, Jeffrey Yu writes: > Do you think it is possible to deploy a better name mangling mechanism > in xsd compiler so variable names can be unique and don't collide > With the user-defined variables? This is a hard problem. If the translation (XML Schema to C++ in our case) adds any names then there is always a chance they will conflict with the ones in the source. So the only true solution to this problem is not to add any names which is not really an option in our case. There are further complication with, for example, C++ not allowing a member function to have the same name as the class. In XML Schema you can have a type and an element/attribute inside this type with the same name. > In short, it is the preprocessors placed in top of the .hxx have the > different names caused the problem. You can override the include guard prefix with the --guard-prefix option, for example: $ xsd cxx-tree foo/bar.xsd In this case the guard will be FOO_BAR_HXX. If we add the option: $ xsd cxx-tree --guard-prefix p foo/bar.xsd the guard will be P_BAR_HXX regardless of the path to the schema. Boris From jeffrey.yu at panpacificinvestment.com Mon Oct 6 13:40:43 2008 From: jeffrey.yu at panpacificinvestment.com (Jeffrey Yu) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] different behavior by xsd 3.0 and 3.2 In-Reply-To: <20081006165851.GA20312@karelia> References: <000301c927b1$8bc46b50$a34d41f0$%yu@panpacificinvestment.com> <20081006132854.GA19415@karelia> <000001c927c4$19e9b630$4dbd2290$%yu@panpacificinvestment.com> <20081006165851.GA20312@karelia> Message-ID: <000001c927da$a879d400$f96d7c00$%yu@panpacificinvestment.com> Hi Boris, The --guard-prefix helps fix the problem. Thanks. What I meant on "better name mangling mechanism" is when xsd compiler generates variables according to the user xsd file, it might maintain a map between its internal ones and user's, in addition to the one's created in order to generate the data object. In the problem I ran into, it happens my variable value_type collides with xsd's value_type for value. When xsd compiler generates its internal variables, can it, let say, add __ as suffix on each external variables so it can reduce the likelihood of bumping the external one off the map? It shouldn't be that difficult as I see it, you are adding the suffix _value to the external variables, what if the algorithm is __value_ instead, I mean, it would be less likely for programmers use complex naming convention __value_ on their own. Just a thought. Jeff -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, October 06, 2008 12:59 PM To: Jeffrey Yu Cc: 'XSD-users' Subject: Re: [xsd-users] different behavior by xsd 3.0 and 3.2 Hi Jeffrey, Jeffrey Yu writes: > Do you think it is possible to deploy a better name mangling mechanism > in xsd compiler so variable names can be unique and don't collide > With the user-defined variables? This is a hard problem. If the translation (XML Schema to C++ in our case) adds any names then there is always a chance they will conflict with the ones in the source. So the only true solution to this problem is not to add any names which is not really an option in our case. There are further complication with, for example, C++ not allowing a member function to have the same name as the class. In XML Schema you can have a type and an element/attribute inside this type with the same name. > In short, it is the preprocessors placed in top of the .hxx have the > different names caused the problem. You can override the include guard prefix with the --guard-prefix option, for example: $ xsd cxx-tree foo/bar.xsd In this case the guard will be FOO_BAR_HXX. If we add the option: $ xsd cxx-tree --guard-prefix p foo/bar.xsd the guard will be P_BAR_HXX regardless of the path to the schema. Boris From chuck.mayne at hp.com Thu Oct 9 15:52:25 2008 From: chuck.mayne at hp.com (Mayne, Chuck (ICS-San Diego)) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Any possibility of using MSXML rather than Xerces? Message-ID: <0491AA4FA048CE44B2B04BA5367AD03731650CD5F9@GVW0442EXB.americas.hpqcorp.net> Hi Boris, Is there any possibility of using MSXML as the DOM parser rather than Xerces? If it is not possible with the current release, is this feature on the roadmap for future support? I have been evaluating the CodeSynthesis XSD tree generator as a potential tool for my current project, but the environment our software builds and runs in requires MSXML. I have found nothing in the documentation or the code samples I have generated to suggest that MSXML could be substituted for the Xerces parser. Thanks and regards, Chuck Mayne From boris at codesynthesis.com Thu Oct 9 17:15:06 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Any possibility of using MSXML rather than Xerces? In-Reply-To: <0491AA4FA048CE44B2B04BA5367AD03731650CD5F9@GVW0442EXB.americas.hpqcorp.net> References: <0491AA4FA048CE44B2B04BA5367AD03731650CD5F9@GVW0442EXB.americas.hpqcorp.net> Message-ID: <20081009211506.GC3358@karelia> Hi Chuck, Mayne, Chuck (ICS-San Diego) writes: > Is there any possibility of using MSXML as the DOM parser rather > than Xerces? If it is not possible with the current release, is > this feature on the roadmap for future support? It is not possible and it is currently not on the roadmap. XSD is a cross-platform tool that is intended to work consistently across all major operating systems. Supporting Windows-only MSXML in this setting does not make much sense. There is one thing that can be done, however. The XSD-generated code (for the C++/Tree mapping) works off Xerces-C++ DOM. So what you can do is translate MSXML DOM to Xerces-C++ DOM and then feed that to the XSD-generated code. This will allow you to use MSXML for parsing. While the Xerces-C++ library is not small (about 1.7Mb on Windows) one can strip off all the parsing code and only leave DOM classes. This should reduce the library size dramatically. Boris From Raymond.Rizzuto at sig.com Thu Oct 9 18:27:16 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint Message-ID: I'm hitting an out of memory issue with my application. The app creates an instance of an XML type SimpleOrder that represents a stock order. It keeps it around so that it can update and output it as XML to a consuming system whenever the stock order is updated. It turns out that many orders are long-lived, so once I get about 2000 orders, I start getting bad_malloc exceptions, and it is all downhill from that point. The app runs under Linux, 32 bit. It grows in virtual image size, as reported by top, from an initial 100meg to ~3gig. If I comment out the logic that creates/updates the SimpleOrder, there is no memory growth, so it seems very likely that the issue is the size of the in memory object. This works out to about 1.5meg per SimpleOrder, which seems excessive since it is under 3K serialized out as XML. Is there any way to reduce the memory footprint? Baring that, I may want to save the SimpleOrder out to a file or db when not in use. I.e. serialize/deserialize it via XML, or possible Boost's serialization library. However, I am concerned about the performance hit of that approach. Ray IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From boris at codesynthesis.com Fri Oct 10 08:49:27 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint In-Reply-To: References: Message-ID: <20081010124927.GB4986@karelia> Hi Ray, Rizzuto, Raymond writes: > The app runs under Linux, 32 bit. It grows in virtual image size, as > reported by top, from an initial 100meg to ~3gig. If I comment out > the logic that creates/updates the SimpleOrder, there is no memory > growth, so it seems very likely that the issue is the size of the > in memory object. This works out to about 1.5meg per SimpleOrder, > which seems excessive since it is under 3K serialized out as XML. A 1.5Mb object model for a 3Kb XML file definitely doesn't sound right. I've created a small test case with a memory profiler (based on operator new/delete overloading). I used the schema from the library example which is quite heavy on structure (i.e., has a number of sequences and optional members as well as small chunks of data) so it should be closer to the worst case scenario on the footprint aspect. The test first creates an object model that, when serialized (without pretty-printing), results in a 3Kb XML file. The test measures various memory parameters during this creation. Here is the result on 32-bit GNU/Linux box using g++ 4.1.3: allocate: count: 182 bytes: 5504 free: count: 4 bytes: 60 So the object model takes 5444 bytes. I did some investigation into where the memory goes and most of the overhead comes from string/sequence/containment management data. For example, std::string has 13 bytes overhead. When it holds the "Test author" string, the overhead is greater than the payload. If there were more of the actual data (e.g., longer strings, greater number of elements in sequences, etc.) then the overhead would becomes less of an issue. The second part of the test clones this object model a number of times. Here is the output for 1000 clones: allocate: count: 130000 bytes: 4260000 free: count: 0 bytes: 0 The size per copy is 4260 bytes. It might be surprising that it is less than 5444 bytes taken by the initial object. This is due to the COW semantics of the std::string. All copies share the same string literals as the initial object. Based on this test I tend to think that there is either something special about your SimpleOrder schema or there is something else going on. Perhaps you could profile the creation of a sample SimpleOrder object as I did for the library schema. The test case is available here: http://www.codesynthesis.com/~boris/tmp/memprof.tar.gz I would be interested to know the number that you get. Boris From Raymond.Rizzuto at sig.com Fri Oct 10 09:57:56 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint In-Reply-To: <20081010124927.GB4986@karelia> References: <20081010124927.GB4986@karelia> Message-ID: Boris, I rebuilt your application using these options, which are what I use in my application: We are using gcc 3.3.3 on SLES 9, 32 bit. Here are the numbers as reported when I run the app: allocate: count: 113 bytes: 4132 free: count: 0 bytes: 0 allocate: count: 11303 bytes: 433888 free: count: 0 bytes: 0 Strangely, the application take a while to exit. I'm not sure if that is significant or not. I'm going to see if I can perform the same experiment with my application. Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 10, 2008 8:49 AM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] in memory footprint Hi Ray, Rizzuto, Raymond writes: > The app runs under Linux, 32 bit. It grows in virtual image size, as > reported by top, from an initial 100meg to ~3gig. If I comment out > the logic that creates/updates the SimpleOrder, there is no memory > growth, so it seems very likely that the issue is the size of the > in memory object. This works out to about 1.5meg per SimpleOrder, > which seems excessive since it is under 3K serialized out as XML. A 1.5Mb object model for a 3Kb XML file definitely doesn't sound right. I've created a small test case with a memory profiler (based on operator new/delete overloading). I used the schema from the library example which is quite heavy on structure (i.e., has a number of sequences and optional members as well as small chunks of data) so it should be closer to the worst case scenario on the footprint aspect. The test first creates an object model that, when serialized (without pretty-printing), results in a 3Kb XML file. The test measures various memory parameters during this creation. Here is the result on 32-bit GNU/Linux box using g++ 4.1.3: allocate: count: 182 bytes: 5504 free: count: 4 bytes: 60 So the object model takes 5444 bytes. I did some investigation into where the memory goes and most of the overhead comes from string/sequence/containment management data. For example, std::string has 13 bytes overhead. When it holds the "Test author" string, the overhead is greater than the payload. If there were more of the actual data (e.g., longer strings, greater number of elements in sequences, etc.) then the overhead would becomes less of an issue. The second part of the test clones this object model a number of times. Here is the output for 1000 clones: allocate: count: 130000 bytes: 4260000 free: count: 0 bytes: 0 The size per copy is 4260 bytes. It might be surprising that it is less than 5444 bytes taken by the initial object. This is due to the COW semantics of the std::string. All copies share the same string literals as the initial object. Based on this test I tend to think that there is either something special about your SimpleOrder schema or there is something else going on. Perhaps you could profile the creation of a sample SimpleOrder object as I did for the library schema. The test case is available here: http://www.codesynthesis.com/~boris/tmp/memprof.tar.gz I would be interested to know the number that you get. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From Raymond.Rizzuto at sig.com Fri Oct 10 10:09:54 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint References: <20081010124927.GB4986@karelia> Message-ID: The slow exit was all the static allocations being deallocated, and the memory tracker not finding them because of the mem_reset's. To get around that, I added a mem_track flag, default false, so that I can keep the tracking off till main starts, and turn it off before main exits. Ray -----Original Message----- From: Rizzuto, Raymond Sent: Friday, October 10, 2008 9:58 AM To: 'Boris Kolpackov'; Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: RE: [xsd-users] in memory footprint Boris, I rebuilt your application using these options, which are what I use in my application: We are using gcc 3.3.3 on SLES 9, 32 bit. Here are the numbers as reported when I run the app: allocate: count: 113 bytes: 4132 free: count: 0 bytes: 0 allocate: count: 11303 bytes: 433888 free: count: 0 bytes: 0 Strangely, the application take a while to exit. I'm not sure if that is significant or not. I'm going to see if I can perform the same experiment with my application. Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 10, 2008 8:49 AM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] in memory footprint Hi Ray, Rizzuto, Raymond writes: > The app runs under Linux, 32 bit. It grows in virtual image size, as > reported by top, from an initial 100meg to ~3gig. If I comment out > the logic that creates/updates the SimpleOrder, there is no memory > growth, so it seems very likely that the issue is the size of the > in memory object. This works out to about 1.5meg per SimpleOrder, > which seems excessive since it is under 3K serialized out as XML. A 1.5Mb object model for a 3Kb XML file definitely doesn't sound right. I've created a small test case with a memory profiler (based on operator new/delete overloading). I used the schema from the library example which is quite heavy on structure (i.e., has a number of sequences and optional members as well as small chunks of data) so it should be closer to the worst case scenario on the footprint aspect. The test first creates an object model that, when serialized (without pretty-printing), results in a 3Kb XML file. The test measures various memory parameters during this creation. Here is the result on 32-bit GNU/Linux box using g++ 4.1.3: allocate: count: 182 bytes: 5504 free: count: 4 bytes: 60 So the object model takes 5444 bytes. I did some investigation into where the memory goes and most of the overhead comes from string/sequence/containment management data. For example, std::string has 13 bytes overhead. When it holds the "Test author" string, the overhead is greater than the payload. If there were more of the actual data (e.g., longer strings, greater number of elements in sequences, etc.) then the overhead would becomes less of an issue. The second part of the test clones this object model a number of times. Here is the output for 1000 clones: allocate: count: 130000 bytes: 4260000 free: count: 0 bytes: 0 The size per copy is 4260 bytes. It might be surprising that it is less than 5444 bytes taken by the initial object. This is due to the COW semantics of the std::string. All copies share the same string literals as the initial object. Based on this test I tend to think that there is either something special about your SimpleOrder schema or there is something else going on. Perhaps you could profile the creation of a sample SimpleOrder object as I did for the library schema. The test case is available here: http://www.codesynthesis.com/~boris/tmp/memprof.tar.gz I would be interested to know the number that you get. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From Raymond.Rizzuto at sig.com Fri Oct 10 10:12:19 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint References: <20081010124927.GB4986@karelia> Message-ID: I forgot the options: --cxx-suffix .cpp --hxx-suffix .hpp --generate-serialization --generate-polymorphic --generate-ostream --generate-doxygen --generate-comparison --generate-from-base-ctor --generate-wildcard --generate-intellisense --root-element-all Our build system requires the .cpp/.hpp extensions. The others are options I use in my application, so I carried them over. The only options I removed from my normal set were the regex's affecting the name mapping. -----Original Message----- From: Rizzuto, Raymond Sent: Friday, October 10, 2008 9:58 AM To: 'Boris Kolpackov'; Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: RE: [xsd-users] in memory footprint Boris, I rebuilt your application using these options, which are what I use in my application: We are using gcc 3.3.3 on SLES 9, 32 bit. Here are the numbers as reported when I run the app: allocate: count: 113 bytes: 4132 free: count: 0 bytes: 0 allocate: count: 11303 bytes: 433888 free: count: 0 bytes: 0 Strangely, the application take a while to exit. I'm not sure if that is significant or not. I'm going to see if I can perform the same experiment with my application. Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 10, 2008 8:49 AM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] in memory footprint Hi Ray, Rizzuto, Raymond writes: > The app runs under Linux, 32 bit. It grows in virtual image size, as > reported by top, from an initial 100meg to ~3gig. If I comment out > the logic that creates/updates the SimpleOrder, there is no memory > growth, so it seems very likely that the issue is the size of the > in memory object. This works out to about 1.5meg per SimpleOrder, > which seems excessive since it is under 3K serialized out as XML. A 1.5Mb object model for a 3Kb XML file definitely doesn't sound right. I've created a small test case with a memory profiler (based on operator new/delete overloading). I used the schema from the library example which is quite heavy on structure (i.e., has a number of sequences and optional members as well as small chunks of data) so it should be closer to the worst case scenario on the footprint aspect. The test first creates an object model that, when serialized (without pretty-printing), results in a 3Kb XML file. The test measures various memory parameters during this creation. Here is the result on 32-bit GNU/Linux box using g++ 4.1.3: allocate: count: 182 bytes: 5504 free: count: 4 bytes: 60 So the object model takes 5444 bytes. I did some investigation into where the memory goes and most of the overhead comes from string/sequence/containment management data. For example, std::string has 13 bytes overhead. When it holds the "Test author" string, the overhead is greater than the payload. If there were more of the actual data (e.g., longer strings, greater number of elements in sequences, etc.) then the overhead would becomes less of an issue. The second part of the test clones this object model a number of times. Here is the output for 1000 clones: allocate: count: 130000 bytes: 4260000 free: count: 0 bytes: 0 The size per copy is 4260 bytes. It might be surprising that it is less than 5444 bytes taken by the initial object. This is due to the COW semantics of the std::string. All copies share the same string literals as the initial object. Based on this test I tend to think that there is either something special about your SimpleOrder schema or there is something else going on. Perhaps you could profile the creation of a sample SimpleOrder object as I did for the library schema. The test case is available here: http://www.codesynthesis.com/~boris/tmp/memprof.tar.gz I would be interested to know the number that you get. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From boris at codesynthesis.com Fri Oct 10 10:18:42 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint In-Reply-To: References: <20081010124927.GB4986@karelia> Message-ID: <20081010141842.GA19069@karelia> Hi Ray, Rizzuto, Raymond writes: > The slow exit was all the static allocations being deallocated, > and the memory tracker not finding them because of the mem_reset's. Yes, it is a very crude memory profiler ;-). It slows down memory allocations/deallocations significantly due to the linear search used in mem_map. The speed of the test shouldn't be used as any kind of indication of what it will be in the actual application. Boris From Raymond.Rizzuto at sig.com Fri Oct 10 10:51:21 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint In-Reply-To: <20081010141842.GA19069@karelia> References: <20081010124927.GB4986@karelia> <20081010141842.GA19069@karelia> Message-ID: I added the instrumentation code to a simple test app I have that creates a simpleOrder. Here are the printouts after the creation of the simple order, and afterward its destruction: Creation: allocate: count: 1199 bytes: 5314880 free: count: 954 bytes: 3715352 Destruction: allocate: count: 1199 bytes: 5314880 free: count: 1191 bytes: 5305740 Based on the creation counts, it does look like the simpleOrder is holding on to ~1.2meg of memory, which jibes with the growth I saw in the process size. I need to look into why there are 8 allocations that aren't freed once the simpleOrder goes away - that is a bit disturbing, although 2 orders of magnitude smaller than the size of the simpleOrder. Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 10, 2008 10:19 AM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] in memory footprint Hi Ray, Rizzuto, Raymond writes: > The slow exit was all the static allocations being deallocated, > and the memory tracker not finding them because of the mem_reset's. Yes, it is a very crude memory profiler ;-). It slows down memory allocations/deallocations significantly due to the linear search used in mem_map. The speed of the test shouldn't be used as any kind of indication of what it will be in the actual application. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From Raymond.Rizzuto at sig.com Fri Oct 10 13:05:25 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint In-Reply-To: <20081010141842.GA19069@karelia> References: <20081010124927.GB4986@karelia> <20081010141842.GA19069@karelia> Message-ID: One thing I forgot to mention is that I am using xerces 2.7, mainly because that is what the company standard currently is. I decided to set a breakpoint at the mem_allocate method, and look at any unusual allocations. I see some that seem that way to me: mem_allocate (s=65536) at SDMPTest.cpp:60 #1 0x08058945 in operator new (size=65536) at SDMPTest.cpp:152 #2 0x405a610c in xercesc_2_7::MemoryManagerImpl::allocate () from /siglinux/tc/sles9sp4_gcc-3.3.3_i686/sig1/xerces-c-2.7.0/lib/libxerces-c.so.27 #3 0x405447a1 in xercesc_2_7::DOMDocumentImpl::allocate () from /siglinux/tc/sles9sp4_gcc-3.3.3_i686/sig1/xerces-c-2.7.0/lib/libxerces-c.so.27 #4 0x40542242 in xercesc_2_7::DOMDocumentImpl::DOMDocumentImpl () from /siglinux/tc/sles9sp4_gcc-3.3.3_i686/sig1/xerces-c-2.7.0/lib/libxerces-c.so.27 #5 0x405532c7 in xercesc_2_7::DOMImplementationImpl::createDocument () from /siglinux/tc/sles9sp4_gcc-3.3.3_i686/sig1/xerces-c-2.7.0/lib/libxerces-c.so.27 #6 0x4030f70f in xsd::cxx::xml::dom::create_document () at ../../../../../../Include/xsd/cxx/xml/dom/wildcard-source.txx:32 #7 0x401a9271 in Venue (this=0x811371c, id=@0xbfffeda0) at SDMP.cpp:11091 #8 0x0805eaa1 in Converter (this=0x81136e0) at SDMPTest.cpp:772 #9 0x08060e29 in Converter::instance () at SDMPTest.cpp:259 #10 0x0805f60f in main (argc=1, argv=0xbfffeea4) at SDMPTest.cpp:809 I see a similar back trace for each constructor. I made a couple of changes to my options file: 1) removed --generate-wildcard 2) changed --root-element-all to --root-element message since I only ever serialize message This seems to have made a significant improvement - the memory footprint is appox. 4k now! I'm not sure which of those 2 changes, or both, were responsible, but I am very glad for that memory usage is now 1/300th of what it was! Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 10, 2008 10:19 AM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] in memory footprint Hi Ray, Rizzuto, Raymond writes: > The slow exit was all the static allocations being deallocated, > and the memory tracker not finding them because of the mem_reset's. Yes, it is a very crude memory profiler ;-). It slows down memory allocations/deallocations significantly due to the linear search used in mem_map. The speed of the test shouldn't be used as any kind of indication of what it will be in the actual application. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From boris at codesynthesis.com Fri Oct 10 15:37:45 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint In-Reply-To: References: <20081010124927.GB4986@karelia> <20081010141842.GA19069@karelia> Message-ID: <20081010193745.GA19861@karelia> Hi Ray, Rizzuto, Raymond writes: > 1) removed --generate-wildcard Ok, this explains it. Your schema has a wildcard and when this option is present the wildcard content is stored as a DOM fragment. To have a DOM fragment in Xerces-C++ one needs a DOM document. To support this each type that has one or more wildcards also contains a DOM document in which wildcard content is stored. This document is around even if there is no wildcard content set in the object. I modified my test to include an optional xsd:any in each book objects. That means that there will be total 16 DOM documents per library object. Here is what I get with various versions of Xerces-C++: 2.7.0: allocate: count: 365 bytes: 1064116 free: count: 84 bytes: 1180 2.8.0: allocate: count: 349 bytes: 277588 free: count: 68 bytes: 1020 3.0.0: allocate: count: 326 bytes: 32000 free: count: 68 bytes: 1020 As you can see empty DOM documents in Xerces-C++ 2.7.0 are quite expensive. Things got a bit better in 2.8.0 once exponential growth of the DOM heap was implemented. Xerces-C++ 3.0.0 reduced the empty document overhead significantly. Furthermore, Xerces-C++ 3.0.0 allows you to tune global DOM heap allocation parameters (e.g., initial allocation size) as well as on the per-document basis. Boris From Raymond.Rizzuto at sig.com Fri Oct 10 15:53:01 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] in memory footprint In-Reply-To: <20081010193745.GA19861@karelia> References: <20081010124927.GB4986@karelia> <20081010141842.GA19069@karelia> <20081010193745.GA19861@karelia> Message-ID: Boris, Well, that jibes with what I saw when I took the same test code, including the mem_allocate code you sent me, and built under Window. I was using xerces 3.0.0 there, and didn't see any 65536 byte allocations. For now, I can live without the --generate-wildcard option since I'm only generating XML, and consuming what I generate (in debug mode only). I'm going to look into moving to the 3.0.0 version of xerces as part of moving off sles9 and gcc 3.3.3. It's a very old environment, and has other issues as well. Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 10, 2008 3:38 PM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] in memory footprint Hi Ray, Rizzuto, Raymond writes: > 1) removed --generate-wildcard Ok, this explains it. Your schema has a wildcard and when this option is present the wildcard content is stored as a DOM fragment. To have a DOM fragment in Xerces-C++ one needs a DOM document. To support this each type that has one or more wildcards also contains a DOM document in which wildcard content is stored. This document is around even if there is no wildcard content set in the object. I modified my test to include an optional xsd:any in each book objects. That means that there will be total 16 DOM documents per library object. Here is what I get with various versions of Xerces-C++: 2.7.0: allocate: count: 365 bytes: 1064116 free: count: 84 bytes: 1180 2.8.0: allocate: count: 349 bytes: 277588 free: count: 68 bytes: 1020 3.0.0: allocate: count: 326 bytes: 32000 free: count: 68 bytes: 1020 As you can see empty DOM documents in Xerces-C++ 2.7.0 are quite expensive. Things got a bit better in 2.8.0 once exponential growth of the DOM heap was implemented. Xerces-C++ 3.0.0 reduced the empty document overhead significantly. Furthermore, Xerces-C++ 3.0.0 allows you to tune global DOM heap allocation parameters (e.g., initial allocation size) as well as on the per-document basis. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From Brian.Kohan at jhuapl.edu Fri Oct 10 17:36:09 2008 From: Brian.Kohan at jhuapl.edu (Brian Kohan) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Assertion fails when parsing xerces DOMDocument with keep_dom flag Message-ID: <48EFCAC9.60509@jhuapl.edu> I am trying to upgrade from Xerces2.7 to 3.0 and from XSD 2.3.1 to 3.2. The following code worked in 2.3.1 but is now generating an assertion failure: XMLPlatformUtils::Initialize(); XercesDOMParser* parser = new XercesDOMParser(); parser->parse(docUri); DOMDocument* doc = parser->adoptDocument(); MyType* myObj = new MyType(*doc->getDocumentElement(), xml_schema::flags::keep_dom | xml_schema::flags::dont_initialize | xml_schema::flags::dont_validate ); This code works if you remove the keep_dom flag. If left in, I get this: /usr/local/include/xsd/cxx/tree/elements.hxx:698: xsd::cxx::tree::_type::dom_element_info::dom_element_info(xercesc_3_0::DOMElement&, xsd::cxx::tree::type&, bool): Assertion `pd != 0' failed. I'm using the GNU/Linux x86_64 pre-built binary distribution. Any thoughts? Am I doing something incorrectly? Thankyou, Brian Kohan From boris at codesynthesis.com Mon Oct 13 10:03:52 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Assertion fails when parsing xerces DOMDocument with keep_dom flag In-Reply-To: <48EFCAC9.60509@jhuapl.edu> References: <48EFCAC9.60509@jhuapl.edu> Message-ID: <20081013140352.GB5427@karelia> Hi Brian, Brian Kohan writes: > I am trying to upgrade from Xerces2.7 to 3.0 and from XSD 2.3.1 to 3.2. > The following code worked in 2.3.1 but is now generating an assertion > failure: > > XMLPlatformUtils::Initialize(); > XercesDOMParser* parser = new XercesDOMParser(); > parser->parse(docUri); > DOMDocument* doc = parser->adoptDocument(); > > MyType* myObj = new MyType(*doc->getDocumentElement(), > xml_schema::flags::keep_dom | > xml_schema::flags::dont_initialize | > xml_schema::flags::dont_validate > ); In XSD 3.1.0 we have implemented exception-safe DOMDocument ownership transfer which requires that the xml_schema::dom::auto_ptr object owning the DOMDocument be associated with the DOMDocument itself so that the generated code can reset it when it assumes the ownership. All this is normally done under the hood by one of the parsing functions but since you are using the parsing constructors directly, you will need to do it yourself: xml_schema::dom::auto_ptr doc = parser->adoptDocument(); doc->setUserData (xml_schema::dom::tree_node_key, doc.get (), 0); MyType* myObj = new MyType(*doc->getDocumentElement(), xml_schema::flags::keep_dom | xml_schema::flags::dont_initialize | xml_schema::flags::dont_validate); After the successful construction, myObj will own the DOM document and doc will be reset. If the construction fails then doc still owns the document. Boris From george at sbdev.net Wed Oct 15 12:00:07 2008 From: george at sbdev.net (George Vassilakes) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] XSD serialize to and from wstring Message-ID: <48F61387.4000200@sbdev.net> Hi, The project I am working on passes XML documents as messages between different systems in memory. I have been using XSD generated XML binding code with char without any problems. I use the --generate-serialization option to generate the cpp. Then I use the istringstrem and ostringstream to parse the string that contains the XML document or write to it. When I changed to using wchar_t (option --char-type wchar_t) I expected that the code would generate serialization functions using wisstringstream and wostringstream. This does not work for me as it would mean converting back to UTF-8 and would lose data. How do I do this? Thanks George From boris at codesynthesis.com Wed Oct 15 14:07:20 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] XSD serialize to and from wstring In-Reply-To: <48F61387.4000200@sbdev.net> References: <48F61387.4000200@sbdev.net> Message-ID: <20081015180720.GB14901@karelia> Hi George, George Vassilakes writes: > When I changed to using wchar_t (option --char-type wchar_t) I expected > that the code would generate serialization functions using > wisstringstream and wostringstream. Because an XML document can be in a variety of encodings with different character sizes (e.g., UTF-8, UTF-16, and UTF-32) the document stream is always treated as a byte sequence. This is why, for example, you can open a UTF-32 XML file with std::ifstream and parse it with one of the parsing functions. Similarly, you can write the object model to std::ofstream in UTF-32 using one of the serialization functions. One way to parse std::wstring is to use the MemBufInputSource class provided by Xerces-C++. The following code fragments assume that you are using the latest version of XSD (3.2.0) and that root_t is the root type and root() is the name of the parsing/serialization functions: #include #include #include using namespace xercesc; std::wstring s = ... std::auto_ptr r; XMLPlatformUtils::Initialize (); { MemBufInputSource is (reinterpret_cast (s.c_str ()), s.size () * sizeof (wchar_t)); // If the XML document in s does not specify the encoding in // XML declaration, then you may also need to set the encoding: // // if (sizeof (wchar_t) == 2) // { // is.setEncoding (XMLUni::fgUTF16EncodingString); // UTF-16 // } // else // { // is.setEncoding (XMLUni::fgUCS4EncodingString); // UTF-32 // } r = root (is); } XMLPlatformUtils::Terminate (); Similarly, to serialize to std::wstring one can use MemBufFormatTarget: #include #include using namespace xercesc; std::auto_ptr r = ...; std::wstring s; XMLPlatformUtils::Initialize (); { MemBufFormatTarget ft (512); // First argument is the initial buf size. xml_schema::namespace_infomap map; // Fill in the map. root (ft, *r, map, (sizeof (wchar_t) == 2 ? "UTF-16" : "UTF-32")); s.assign (reinterpret_cast (ft.getRawBuffer ()), ft.getLen () / sizeof (wchar_t)); } XMLPlatformUtils::Terminate (); It is also possible to do the same via the std::istream/std::ostream interfaces. For that you will need to implement your own stream buffers that read/write directly from/to std::wstring as a byte sequence. The zc_istream implementation in libxsd/xsd/cxx/zc_istream.* can help get you started if you are interested in this approach. Boris From george at sbdev.net Thu Oct 16 05:04:28 2008 From: george at sbdev.net (George Vassilakes) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] XSD serialize to and from wstring In-Reply-To: <20081015180720.GB14901@karelia> References: <48F61387.4000200@sbdev.net> <20081015180720.GB14901@karelia> Message-ID: <48F7039C.5030206@sbdev.net> Hi Boris, Thanks for the reply. This seems to work fine. Another question I have is if its possible to get xsd to generate c++ header files describing the schema so when the application runs it does not need to find the .xsd file on the disk. Is it possible to supply this file from memory? What I would like to do is to get my executable running without requiring to find the .xsd files on some location on the disk. Regards George Boris Kolpackov wrote: > Hi George, > > George Vassilakes writes: > > >> When I changed to using wchar_t (option --char-type wchar_t) I expected >> that the code would generate serialization functions using >> wisstringstream and wostringstream. >> > > Because an XML document can be in a variety of encodings with > different character sizes (e.g., UTF-8, UTF-16, and UTF-32) the > document stream is always treated as a byte sequence. This is > why, for example, you can open a UTF-32 XML file with > std::ifstream and parse it with one of the parsing functions. > Similarly, you can write the object model to std::ofstream > in UTF-32 using one of the serialization functions. > > One way to parse std::wstring is to use the MemBufInputSource > class provided by Xerces-C++. The following code fragments > assume that you are using the latest version of XSD (3.2.0) > and that root_t is the root type and root() is the name of > the parsing/serialization functions: > > #include > #include > #include > > using namespace xercesc; > > std::wstring s = ... > std::auto_ptr r; > > XMLPlatformUtils::Initialize (); > > { > MemBufInputSource is (reinterpret_cast (s.c_str ()), > s.size () * sizeof (wchar_t)); > > // If the XML document in s does not specify the encoding in > // XML declaration, then you may also need to set the encoding: > // > // if (sizeof (wchar_t) == 2) > // { > // is.setEncoding (XMLUni::fgUTF16EncodingString); // UTF-16 > // } > // else > // { > // is.setEncoding (XMLUni::fgUCS4EncodingString); // UTF-32 > // } > > r = root (is); > } > > XMLPlatformUtils::Terminate (); > > Similarly, to serialize to std::wstring one can use MemBufFormatTarget: > > > #include > #include > > using namespace xercesc; > > std::auto_ptr r = ...; > std::wstring s; > > XMLPlatformUtils::Initialize (); > > { > MemBufFormatTarget ft (512); // First argument is the initial buf size. > > xml_schema::namespace_infomap map; > > // Fill in the map. > > root (ft, *r, map, (sizeof (wchar_t) == 2 ? "UTF-16" : "UTF-32")); > > s.assign (reinterpret_cast (ft.getRawBuffer ()), > ft.getLen () / sizeof (wchar_t)); > } > > XMLPlatformUtils::Terminate (); > > It is also possible to do the same via the std::istream/std::ostream > interfaces. For that you will need to implement your own stream > buffers that read/write directly from/to std::wstring as a byte > sequence. The zc_istream implementation in libxsd/xsd/cxx/zc_istream.* > can help get you started if you are interested in this approach. > > Boris > > > From boris at codesynthesis.com Thu Oct 16 05:39:50 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] XSD serialize to and from wstring In-Reply-To: <48F7039C.5030206@sbdev.net> References: <48F61387.4000200@sbdev.net> <20081015180720.GB14901@karelia> <48F7039C.5030206@sbdev.net> Message-ID: <20081016093950.GA17650@karelia> Hi George, George Vassilakes writes: > Another question I have is if its possible to get xsd to generate c++ > header files describing the schema so when the application runs it does > not need to find the .xsd file on the disk. Is it possible to supply > this file from memory? > What I would like to do is to get my executable running without > requiring to find the .xsd files on some location on the disk. There are two ways you can achieve this. The first is to embed the schema into your application as a text file or string and then load it before parsing XML documents. This approach is described in the following posts to xsd-users: http://www.codesynthesis.com/pipermail/xsd-users/2006-September/000536.html http://www.codesynthesis.com/pipermail/xsd-users/2006-September/000540.html This approach gets complicated if you need to embed schemas with imports/includes. The easiest way to handle this situation is to use the binary representation of the schema grammar instead of the text representation. Xerces-C++ support storing pre-parsed schema grammar (all the imported/included schemas as one grammar object) in a binary format which you can then embed into your application and load at runtime. It has an extra benefit of being quite a bit faster than parsing the actual schemas. The following article on IBM developerWorks has more information on the binary grammar serialization feature: http://www-128.ibm.com/developerworks/webservices/library/x-xsdxerc.html It is also possible to use textual representation in multi-schema case. For this to work you will need to implement XMLEntityResolver interface which, if provided, gets called to resolve various external entities, including included/imported schema files. In your implementation you could search a map of embedded files and return MemBufInputSource for each. Boris From george at sbdev.net Thu Oct 16 06:26:34 2008 From: george at sbdev.net (George Vassilakes) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] XSD serialize to and from wstring In-Reply-To: <20081016093950.GA17650@karelia> References: <48F61387.4000200@sbdev.net> <20081015180720.GB14901@karelia> <48F7039C.5030206@sbdev.net> <20081016093950.GA17650@karelia> Message-ID: <48F716DA.6080408@sbdev.net> Thanks this is very helpful. Boris Kolpackov wrote: > Hi George, > > George Vassilakes writes: > > >> Another question I have is if its possible to get xsd to generate c++ >> header files describing the schema so when the application runs it does >> not need to find the .xsd file on the disk. Is it possible to supply >> this file from memory? >> What I would like to do is to get my executable running without >> requiring to find the .xsd files on some location on the disk. >> > > There are two ways you can achieve this. The first is to embed the > schema into your application as a text file or string and then > load it before parsing XML documents. This approach is described > in the following posts to xsd-users: > > http://www.codesynthesis.com/pipermail/xsd-users/2006-September/000536.html > http://www.codesynthesis.com/pipermail/xsd-users/2006-September/000540.html > > This approach gets complicated if you need to embed schemas with > imports/includes. The easiest way to handle this situation is to > use the binary representation of the schema grammar instead of the > text representation. Xerces-C++ support storing pre-parsed schema > grammar (all the imported/included schemas as one grammar object) > in a binary format which you can then embed into your application > and load at runtime. It has an extra benefit of being quite a bit > faster than parsing the actual schemas. The following article on > IBM developerWorks has more information on the binary grammar > serialization feature: > > http://www-128.ibm.com/developerworks/webservices/library/x-xsdxerc.html > > It is also possible to use textual representation in multi-schema > case. For this to work you will need to implement XMLEntityResolver > interface which, if provided, gets called to resolve various > external entities, including included/imported schema files. > In your implementation you could search a map of embedded files > and return MemBufInputSource for each. > > Boris > > > From george at sbdev.net Thu Oct 16 11:36:33 2008 From: george at sbdev.net (George Vassilakes) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Fixed Attributes In-Reply-To: <20081016093950.GA17650@karelia> References: <48F61387.4000200@sbdev.net> <20081015180720.GB14901@karelia> <48F7039C.5030206@sbdev.net> <20081016093950.GA17650@karelia> Message-ID: <48F75F81.3060704@sbdev.net> Hi, Is it possible to get the XSD generated classes when serializing to XML to also include the fixed value attributes? for example if I have the following types Base type of all messages on Message.xsd ============================= On another file DTMessage.xsd that includes Message.xsd I define first a restriction that sets the service name and then lots of messages that inherit from it ============================== If I create instances of the DT_EncryptDiskCmd class and serialise them and load the using the DTMessage.xsd then the serviceName is automatically set by the fixed value. However if I parse the XML using the Message.xsd the value is not set as this was not output by the serialization. Is it possible to get it to set these these fixed attributes on the XML when serializing from C++ to XML? Regards George From boris at codesynthesis.com Thu Oct 16 16:44:22 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Fixed Attributes In-Reply-To: <48F75F81.3060704@sbdev.net> References: <48F61387.4000200@sbdev.net> <20081015180720.GB14901@karelia> <48F7039C.5030206@sbdev.net> <20081016093950.GA17650@karelia> <48F75F81.3060704@sbdev.net> Message-ID: <20081016204422.GB20043@karelia> Hi George, George Vassilakes writes: > Is it possible to get the XSD generated classes when serializing to > XML to also include the fixed value attributes? This is the default behavior. All default and fixed attributes are present in the resulting XML unless you specified the --omit-default-attributes option. > If I create instances of the DT_EncryptDiskCmd class and serialise them > and load the using the DTMessage.xsd then the serviceName is > automatically set by the fixed value. > However if I parse the XML using the Message.xsd the value is not set as > this was not output by the serialization. I am having a hard time understanding what you mean by "parse the XML using the Message.xsd". Can you provide a small but compilable example (i.e., a schema, sample XML file, and a test driver) that demonstrates the problem you are observing? Boris From george at sbdev.net Fri Oct 17 04:38:06 2008 From: george at sbdev.net (George Vassilakes) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Fixed Attributes In-Reply-To: <20081016204422.GB20043@karelia> References: <48F61387.4000200@sbdev.net> <20081015180720.GB14901@karelia> <48F7039C.5030206@sbdev.net> <20081016093950.GA17650@karelia> <48F75F81.3060704@sbdev.net> <20081016204422.GB20043@karelia> Message-ID: <48F84EEE.8000803@sbdev.net> Hi Boris, The problem is that when I create a new instance of a class generated by XSD for a type it does not initialise the member attributes with the default/fixed values. So if I then serialize this instance it only writes the attributes that are present to the XML document. If I then parse this document it creates instances of these types that do include these attributes. So basically when it desirializes an XML document the instances include the default/fixed attributes, however when creating a new instance in C++ then these attributes are not set. This is a problem with fixed attributes defined on the supertype consider the following schema Then run the following code #include "Example.hxx" #include #include int main(int argc, char* argv[]) { Example ex; ex.attribute2("att2"); ex.attribute3("att3"); // now print the details it will show that the attribute fixed is not present std::cout << ex.attributeFixed() << std::endl; std::cout << ex.attribute1() << std::endl; std::cout << ex.attribute2() << std::endl; std::cout << ex.attribute3() << std::endl; // serialize xml_schema::namespace_infomap map; map[""].name = ""; map[""].schema = "Example.xsd"; std::ostringstream stream; Example_(stream, ex, map); // read serialized class and print again std::istringstream is(stream.str()); std::auto_ptr<::Example> ex2 = Example_(is); // now print the details this time attributeFixed is present std::cout << ex2->attributeFixed() << std::endl; std::cout << ex2->attribute1() << std::endl; std::cout << ex2->attribute2() << std::endl; std::cout << ex2->attribute3() << std::endl; system("PAUSE"); return 0; } Regards George Boris Kolpackov wrote: > Hi George, > > George Vassilakes writes: > > >> Is it possible to get the XSD generated classes when serializing to >> XML to also include the fixed value attributes? >> > > This is the default behavior. All default and fixed attributes are > present in the resulting XML unless you specified the > --omit-default-attributes option. > > > >> If I create instances of the DT_EncryptDiskCmd class and serialise them >> and load the using the DTMessage.xsd then the serviceName is >> automatically set by the fixed value. >> However if I parse the XML using the Message.xsd the value is not set as >> this was not output by the serialization. >> > > I am having a hard time understanding what you mean by "parse the XML > using the Message.xsd". Can you provide a small but compilable example > (i.e., a schema, sample XML file, and a test driver) that demonstrates > the problem you are observing? > > Boris > > > From antonio.trindade at logica.com Fri Oct 17 05:57:06 2008 From: antonio.trindade at logica.com (=?iso-8859-1?Q?Trindade=2C_Ant=F3nio?=) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] RE: xsd:ref problem Message-ID: <2DF7E823A96CE14099A003713C64870501E1977C@pt-ex002.groupinfra.com> Hi, I had a similar problem and had to change and create unique namespaces. Do you have a technical explanation for that? Many Thanks, Ant?nio Trindade This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From boris at codesynthesis.com Fri Oct 17 06:23:08 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Fixed Attributes In-Reply-To: <48F84EEE.8000803@sbdev.net> References: <48F61387.4000200@sbdev.net> <20081015180720.GB14901@karelia> <48F7039C.5030206@sbdev.net> <20081016093950.GA17650@karelia> <48F75F81.3060704@sbdev.net> <20081016204422.GB20043@karelia> <48F84EEE.8000803@sbdev.net> Message-ID: <20081017102308.GB21668@karelia> Hi George, George Vassilakes writes: > So basically when it desirializes an XML document the instances include > the default/fixed attributes, however when creating a new instance in > C++ then these attributes are not set. This is a problem with fixed > attributes defined on the supertype > > consider the following schema > > > > > > > > > > > > > > fixed="TEST"/> > > > > substitutionGroup="ExampleBase"/> > > > > > > > > > > > > substitutionGroup="ExampleBase"/> > > Thanks for the example, now I know what's going on. It is quite hard to provide a mapping for complex type restriction in C++ (it quickly becomes a huge bag of special cases). So what we did in the C++/Tree mapping is to ignore it (I am simplifying it a bit here). In your case the ExampleRestr class simply inherits from ExampleBase. In most cases it works just fine but sometimes a useful feature like the above gets ignored as well. The reason why you get the default attribute set when you create the object model from XML is because XML Schema validator in Xerces-C++ "expands" default/fixed attributes. The only solution I can offer at the moment is to "touch up" the ExampleRestr class with type customization and set the default attribute value manually (from your earlier email I gather that you don't have too many of these "intermediate" types). For more information on type customization, see the C++/Tree Mapping Customization Guide: http://wiki.codesynthesis.com/Tree/Customization_guide There is also a bunch of examples in the examples/cxx/tree/custom/ directory with the ones relevant to your case being contacts and taxonomy (they are also discussed in the guide). In your case all you will need to do is set the default attribute value in the default constructor: class ExampleRestr: public ExampleRestr_base { ExampleRestr () { attributeFixed ("TEST"); } // Other c-tors simply forward to ExampleRestr_base // ... }; Boris From george at sbdev.net Fri Oct 17 11:06:17 2008 From: george at sbdev.net (George Vassilakes) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Local disk schema location In-Reply-To: <20081017102308.GB21668@karelia> References: <48F61387.4000200@sbdev.net> <20081015180720.GB14901@karelia> <48F7039C.5030206@sbdev.net> <20081016093950.GA17650@karelia> <48F75F81.3060704@sbdev.net> <20081016204422.GB20043@karelia> <48F84EEE.8000803@sbdev.net> <20081017102308.GB21668@karelia> Message-ID: <48F8A9E9.9070903@sbdev.net> Hi, whats is the syntax for a schema location in an XSD file I tried using schemaLocation="file:///c:\file.xsd" but I get "is not a valid filesystem path" when I run xsd to generate the c++. If I use "../.../file.xsd" it works fine. I also tried using the windows style path but still no luck. At run time if I serialize instances to XML and set the map[""].schema = "c:\file.xsd" and then parse it works ok. Thanks George From boris at codesynthesis.com Fri Oct 17 12:15:01 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] RE: xsd:ref problem In-Reply-To: <2DF7E823A96CE14099A003713C64870501E1977C@pt-ex002.groupinfra.com> References: <2DF7E823A96CE14099A003713C64870501E1977C@pt-ex002.groupinfra.com> Message-ID: <20081017161501.GD21668@karelia> Hi Ant?nio, Trindade, Ant?nio writes: > I had a similar problem and had to change and create unique namespaces. > > Do you have a technical explanation for that? Yes, please see: http://www.codesynthesis.com/pipermail/xsd-users/2008-September/001960.html Boris From boris at codesynthesis.com Fri Oct 17 12:31:38 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] Re: Local disk schema location Message-ID: <20081017163138.GF21668@karelia> Hi George, George Vassilakes writes: > whats is the syntax for a schema location in an XSD file Per the XML Schema spec it is a URI (absolute or relative). However, for security reasons (no network access), the XSD compiler only supports local filesystem paths. > If I use "../.../file.xsd" it works fine. I also tried using > the windows style path but still no luck. Relative (both Windows and POSIX styles, e.g., ../foo/bar.xsd and ..\foo\bar.xsd) as well as absolute (e.g., c:\foo\bar.xsd) paths work for me on Windows with XSD 3.2.0. Which version of XSD are you using? Also if you are planning to use absolute paths for inclusion then you will most likely want to change header include paths in the generated code. For that refer to the --include-regex option. Boris From illes.farkas at gmail.com Sun Oct 19 10:22:36 2008 From: illes.farkas at gmail.com (Farkas, Illes) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] convert 1GB xml to xsd, visualize on webpage Message-ID: Dear List Members, Do you happen to know of a linux tool (or tools) that can extract from a 1-20GB xml file its schema and visualize for users similarly to this page: http://psidev.sourceforge.net/mi/rel25/doc/ If I'm posting this question to the wrong list, could you please suggest another list? Thanks in advance, Illes Farkas, Ph.D. http://angel.elte.hu/fij From boris at codesynthesis.com Sun Oct 19 14:05:01 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] convert 1GB xml to xsd, visualize on webpage In-Reply-To: References: Message-ID: <20081019180501.GA2278@karelia> Hi Illes, Farkas, Illes writes: > Dear List Members, > Do you happen to know of a linux tool (or tools) that can extract from a > 1-20GB xml file its schema and visualize for users similarly to this page: > http://psidev.sourceforge.net/mi/rel25/doc/ > > If I'm posting this question to the wrong list, could you please suggest > another list? I think you will have a better chance of getting a response by posting to the xmlschema-dev and/or xml-dev mailing lists. See the "discussion" item on this page for more information: http://www.w3.org/XML/Schema#dev This mailing list is for CodeSynthesis XSD, XML Schema to C++ data binding compiler. Boris From Raymond.Rizzuto at sig.com Fri Oct 24 15:59:45 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] gcc warning Message-ID: I am working with an element that has an id defined this way: ReferenceDataId is defined as: In one place in my code, I want to get the id out of a constructed object, and pass it to a function taking int. I.e. essentially do this functionTakingAnInt(stock.get_id()); When I compile the code (gcc 3.3.3), I get this warning: SDMPOrderState.cpp: In member function `void sdmp::OrderStateProcessor::handleNew(P)': SDMPOrderState.cpp:634: warning: choosing `xsd::cxx::tree::fundamental_base::operator T&() [with T = int_, C = char, B = xml_schema::simple_type, sd::cxx::tree::schema_type::value ST = other]' over `xsd::cxx::tree::fundamental_base::operator const T&() const [with T = int_, C = char, B = xml_schema::simple_type, xsd::cxx::tree::schema_type::value ST = other]' SDMPOrderState.cpp:634: warning: for conversion from `sdmp::messages::ReferenceDataId' to `int_' SDMPOrderState.cpp:634: warning: because conversion sequence for the argument is better Is there a better method that prevents this warning? Ray ________________________________ Ray Rizzuto raymond.rizzuto@sig.com Susquehanna International Group (610)747-2336 (W) (215)776-3780 (C) ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From dktemp at hotmail.co.uk Sun Oct 26 08:20:41 2008 From: dktemp at hotmail.co.uk (David Kelvin) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] String length Message-ID: Hi, I am testing the code produced with XSD and using Expat as the parser. I have an element tattribute defined in the schema with the following restriction: In the following routine, I had checked the length to verify it is only 1 but it isn't always - it seems to depend on the character: std::string characterType_pimpl:: post_characterType () { const ::std::string& v (post_string ()); /* */ std::cout << "length: " << v.length() << std::endl; std::cout << "character: " << v.c_str() << std::endl; return v; } For example, if the character in the XML file is a normal letter, digit or symbol, then it the length is 1. However, we quite often use the character '?' ("0xbb" or Alt + 0187) and this returns the length of 2 and v.c_str() is "0xc2bb", although when the output is redirected to a text file (UTF-8), only the single character "?" appears. If left to print to the screen, it is a different combination. It looks like a char/wchar_t problem. Thanks David _________________________________________________________________ Win an Xbox 360 or ?200 Top Shop Vouchers http://clk.atdmt.com/GBL/go/115454062/direct/01/ From boris at codesynthesis.com Mon Oct 27 10:04:46 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] gcc warning In-Reply-To: References: Message-ID: <20081027140446.GD6891@karelia> Hi Ray, Rizzuto, Raymond writes: > In one place in my code, I want to get the id out of a constructed object, > and pass it to a function taking int. I.e. essentially do this > > functionTakingAnInt(stock.get_id()); > > When I compile the code (gcc 3.3.3), I get this warning: > > [...] > > Is there a better method that prevents this warning? This is a well-known, bogus warning in older versions of g++. Unfortunately I don't have access to the version that produces this warning so I couldn't test my work-arounds (g++ 3.3.6 as well as 3.2.3 that I have access to don't have this bug). I think the following should work (besides upgrading the compiler, of course): functionTakingAnInt((int&)stock.get_id ()); const ReferenceDataId& id (stock.get_id ()); functionTakingAnInt(id); Making stock const should also help. If you don't plan to modify stock then this might be the cleanest approach. Boris From boris at codesynthesis.com Mon Oct 27 10:26:28 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] String length In-Reply-To: References: Message-ID: <20081027142628.GE6891@karelia> Hi David, David Kelvin writes: > For example, if the character in the XML file is a normal letter, > digit or symbol, then it the length is 1. > > However, we quite often use the character '?' ("0xbb" or Alt + 0187) > and this returns the length of 2 and v.c_str() is "0xc2bb", although > when the output is redirected to a text file (UTF-8), only the single > character "?" appears. If left to print to the screen, it is a > different combination. When the mapping character type is char (currently the only option for the Expat as the underlying parser), all text is passed as UTF-8. UTF-8 is a variable-length encoding which represents each character as a 1 to 4 octet sequence. In your case, Unicode character 0xbb is represented as a 2-octet sequence. Standard C++ string class (std::string) does not know anything about the encoding of the string it holds and it operates in terms of 8-bit octets. This is why length() returns 2. If you need the string length in terms of symbols then you will need to either implement this function yourself or you can use a third- party library, for example ICU (International Components for Unicode): http://icu-project.org/ Boris From dktemp at hotmail.co.uk Mon Oct 27 15:29:28 2008 From: dktemp at hotmail.co.uk (David Kelvin) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] String length In-Reply-To: <20081027142628.GE6891@karelia> References: <20081027142628.GE6891@karelia> Message-ID: Boris, Thank you. I missed the bit that all characters were UTF-8. We do have our own UTF-8 conversion routines. I'll have to investigate how to put this together. Regards,David _________________________________________________________________ X Factor: latest video, features and more. Click here! http://clk.atdmt.com/GBL/go/115454063/direct/01/ From Raymond.Rizzuto at sig.com Mon Oct 27 16:00:12 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] gcc warning In-Reply-To: <20081027140446.GD6891@karelia> References: <20081027140446.GD6891@karelia> Message-ID: Boris, I'm glad to hear that the warning isn't caused by anything I am doing wrong. Unfortunately, I can't move to a new version of gcc till I move to sles 10, which I can't do yet because of other dependencies. I am using the (int &) work-around for now. That works, so I'll use that for now. Thanks again for all the help. Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, October 27, 2008 10:05 AM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] gcc warning Hi Ray, Rizzuto, Raymond writes: > In one place in my code, I want to get the id out of a constructed object, > and pass it to a function taking int. I.e. essentially do this > > functionTakingAnInt(stock.get_id()); > > When I compile the code (gcc 3.3.3), I get this warning: > > [...] > > Is there a better method that prevents this warning? This is a well-known, bogus warning in older versions of g++. Unfortunately I don't have access to the version that produces this warning so I couldn't test my work-arounds (g++ 3.3.6 as well as 3.2.3 that I have access to don't have this bug). I think the following should work (besides upgrading the compiler, of course): functionTakingAnInt((int&)stock.get_id ()); const ReferenceDataId& id (stock.get_id ()); functionTakingAnInt(id); Making stock const should also help. If you don't plan to modify stock then this might be the cleanest approach. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From karina.abayeva at rbccm.com Mon Oct 27 18:50:48 2008 From: karina.abayeva at rbccm.com (Abayeva, Karina) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] xsd:pattern Message-ID: <381066B16350514C8C662EA36DF4B198064BD3D9@SXOM-102.fg.rbc.com> All, I am trying to specify xsd:pattern restriction in my XSD as follows: However, when I generate the class, no code is generated to validate against this pattern. Could you advise what I might be doing wrong? Thanks, Karina ________________________________________ This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. This E-Mail (including any attachments) has been scanned for viruses. It is believed to be free of any virus or other defect that might affect any computer system into which it is received and opened. However, it is the responsibility of the recipient to ensure that it is virus free. The sender accepts no responsibility for any loss or damage arising in any way from its use. E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information. IRS CIRCULAR 230 NOTICE: TO COMPLY WITH U.S. TREASURY REGULATIONS, WE ADVISE YOU THAT ANY U.S. FEDERAL TAX ADVISE INCLUDED IN THIS COMMUNICATION IS NOT INTENDED OR WRITTEN TO BE USED, AND CANNOT BE USED, TO AVOID ANY U.S. FEDERAL TAX PENALTIES OR TO PROMOTE, MARKET, OR RECOMMEND TO ANOTHER PARTY ANY TRANSACTION OR MATTER. From boris at codesynthesis.com Tue Oct 28 06:42:17 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] xsd:pattern In-Reply-To: <381066B16350514C8C662EA36DF4B198064BD3D9@SXOM-102.fg.rbc.com> References: <381066B16350514C8C662EA36DF4B198064BD3D9@SXOM-102.fg.rbc.com> Message-ID: <20081028104217.GB10975@karelia> Hi Karina, Abayeva, Karina writes: > I am trying to specify xsd:pattern restriction in my XSD as follows: > > > > > > > However, when I generate the class, no code is generated to validate > against this pattern. I assume you are using the C++/Tree mapping. In C++/Tree validation is performed by the underlying XML parser (Xerces-C++) during XML parsing. If you are looking for an in-memory validation then you may find the following earlier post informative: http://www.codesynthesis.com/pipermail/xsd-users/2008-January/001443.html Boris From karina.abayeva at rbccm.com Tue Oct 28 07:48:02 2008 From: karina.abayeva at rbccm.com (Abayeva, Karina) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] xsd:pattern In-Reply-To: <20081028104217.GB10975@karelia> References: <381066B16350514C8C662EA36DF4B198064BD3D9@SXOM-102.fg.rbc.com> <20081028104217.GB10975@karelia> Message-ID: <381066B16350514C8C662EA36DF4B198064BD3DB@SXOM-102.fg.rbc.com> Thank you for your response. This makes a lot of sense. -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, October 28, 2008 6:42 AM To: Abayeva, Karina Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] xsd:pattern Hi Karina, Abayeva, Karina writes: > I am trying to specify xsd:pattern restriction in my XSD as follows: > > > > > > > However, when I generate the class, no code is generated to validate > against this pattern. I assume you are using the C++/Tree mapping. In C++/Tree validation is performed by the underlying XML parser (Xerces-C++) during XML parsing. If you are looking for an in-memory validation then you may find the following earlier post informative: http://www.codesynthesis.com/pipermail/xsd-users/2008-January/001443.htm l Boris ________________________________________ This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. This E-Mail (including any attachments) has been scanned for viruses. It is believed to be free of any virus or other defect that might affect any computer system into which it is received and opened. However, it is the responsibility of the recipient to ensure that it is virus free. The sender accepts no responsibility for any loss or damage arising in any way from its use. E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information. IRS CIRCULAR 230 NOTICE: TO COMPLY WITH U.S. TREASURY REGULATIONS, WE ADVISE YOU THAT ANY U.S. FEDERAL TAX ADVISE INCLUDED IN THIS COMMUNICATION IS NOT INTENDED OR WRITTEN TO BE USED, AND CANNOT BE USED, TO AVOID ANY U.S. FEDERAL TAX PENALTIES OR TO PROMOTE, MARKET, OR RECOMMEND TO ANOTHER PARTY ANY TRANSACTION OR MATTER. From abdelkader2006 at gmail.com Wed Oct 29 11:18:20 2008 From: abdelkader2006 at gmail.com (abdelkader.mosbah) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] CodeSynthesis and JAXB Message-ID: <7f3018e60810290818i240af52eh6cc43c561ed310b@mail.gmail.com> Hello, In addition to the generation of C++ data model, does CodeSynthesis permits the serialization and deserialization of xml like JAXB? Thanks for your help. From boris at codesynthesis.com Wed Oct 29 11:25:31 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] CodeSynthesis and JAXB In-Reply-To: <7f3018e60810290818i240af52eh6cc43c561ed310b@mail.gmail.com> References: <7f3018e60810290818i240af52eh6cc43c561ed310b@mail.gmail.com> Message-ID: <20081029152531.GC16442@karelia> Hi, abdelkader.mosbah writes: > In addition to the generation of C++ data model, does CodeSynthesis permits > the serialization and deserialization of xml like JAXB? Yes, it does. For a quick overview of how things work, including conversion of XML to object model and back, I suggest that you read Chapter 2, "Hello World Example" in the C++/Tree Mapping Getting Started Guide: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#2 You can then continue reading the guide for more in-depth information. Boris From sutambe at dre.vanderbilt.edu Wed Oct 29 16:22:02 2008 From: sutambe at dre.vanderbilt.edu (Sumant Tambe) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] sequence copy and xsd:IDREF Message-ID: <4908C5EA.10709@dre.vanderbilt.edu> Hi, I'm getting a seg-fault while trying to access xsd:IDREF attribute in a *copy* of a sequence. For instance, in the library catalog example, "recommends" is an xsd:IDREF attribute. The following code seg-faults when b is a copy but works fine when it is a reference. std::auto_ptr c (catalog_ (argv[1])); catalog::book_sequence b = c->book(); for (catalog::book_const_iterator bi (b.begin ()); bi != b.end (); ++bi) { if (ai->recommends ()) cerr << " Recommends : " << (*ai->recommends ())->title (); } Why is such a difference in the behavior? Thanks, Sumant. From boris at codesynthesis.com Wed Oct 29 16:44:26 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] sequence copy and xsd:IDREF In-Reply-To: <4908C5EA.10709@dre.vanderbilt.edu> References: <4908C5EA.10709@dre.vanderbilt.edu> Message-ID: <20081029204426.GA17941@karelia> Hi Sumant, Sumant Tambe writes: > I'm getting a seg-fault while trying to access xsd:IDREF attribute in a > *copy* of a sequence. For instance, in the library catalog example, > "recommends" is an xsd:IDREF attribute. The following code seg-faults > when b is a copy but works fine when it is a reference. > > std::auto_ptr c (catalog_ (argv[1])); > catalog::book_sequence b = c->book(); > > for (catalog::book_const_iterator bi (b.begin ()); > bi != b.end (); ++bi) > { > if (ai->recommends ()) > cerr << " Recommends : " << (*ai->recommends ())->title (); > } > > Why is such a difference in the behavior? Because when you dereference an IDREF pointer the corresponding ID value is searched in the tree that this object is part of. When you use a reference, the sequence is part of the original tree and the object with ID in question can be located. When you make a copy of the sequence, the copy is on its own and when you try to dereference an IDREF pointer the corresponding ID cannot be found, NULL is returned, and you get a segfault. Generally, it makes little sense to make copies of parts of the tree since it wastes resources. Boris From sutambe at dre.vanderbilt.edu Wed Oct 29 16:53:25 2008 From: sutambe at dre.vanderbilt.edu (Sumant Tambe) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] sequence copy and xsd:IDREF In-Reply-To: <20081029204426.GA17941@karelia> References: <4908C5EA.10709@dre.vanderbilt.edu> <20081029204426.GA17941@karelia> Message-ID: <4908CD45.3060506@dre.vanderbilt.edu> Hi Boris, Agreed that making copies of xml tree is wasteful but isn't copy also supposed to have everything from the original? It should be indistinguishable from the original and therefore, even IDREF should also be present. The IDREF I'm dereferencing points to another book in the same sequence which is there in the copy as well. Only thing that is missing in the copy of the sequence is the root document element. May be implementation of IDREF depends on it. Thanks, Sumant. Boris Kolpackov wrote: > Hi Sumant, > > Sumant Tambe writes: > >> I'm getting a seg-fault while trying to access xsd:IDREF attribute in a >> *copy* of a sequence. For instance, in the library catalog example, >> "recommends" is an xsd:IDREF attribute. The following code seg-faults >> when b is a copy but works fine when it is a reference. >> >> std::auto_ptr c (catalog_ (argv[1])); >> catalog::book_sequence b = c->book(); >> >> for (catalog::book_const_iterator bi (b.begin ()); >> bi != b.end (); ++bi) >> { >> if (ai->recommends ()) >> cerr << " Recommends : " << (*ai->recommends ())->title (); >> } >> >> Why is such a difference in the behavior? > > Because when you dereference an IDREF pointer the corresponding > ID value is searched in the tree that this object is part of. > When you use a reference, the sequence is part of the original > tree and the object with ID in question can be located. When > you make a copy of the sequence, the copy is on its own and > when you try to dereference an IDREF pointer the corresponding > ID cannot be found, NULL is returned, and you get a segfault. > > Generally, it makes little sense to make copies of parts of the > tree since it wastes resources. > > Boris From sutambe at dre.vanderbilt.edu Wed Oct 29 17:07:02 2008 From: sutambe at dre.vanderbilt.edu (Sumant Tambe) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] extending xsd Message-ID: <4908D076.5090702@dre.vanderbilt.edu> Hi Boris, In my xsd generator extension, I'm missing child elements of complex types if the complex type is derived from some other complex type, which defines the children in question. In that case, what can I do to detect that a complex type in schema is a derived type of some other type? Also, how do I get hold of the instance of that base type? Thanks, Sumant. From boris at codesynthesis.com Thu Oct 30 14:10:58 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] sequence copy and xsd:IDREF In-Reply-To: <4908CD45.3060506@dre.vanderbilt.edu> References: <4908C5EA.10709@dre.vanderbilt.edu> <20081029204426.GA17941@karelia> <4908CD45.3060506@dre.vanderbilt.edu> Message-ID: <20081030181058.GD20163@karelia> Hi Sumant, Sumant Tambe writes: > Agreed that making copies of xml tree is wasteful but isn't copy also > supposed to have everything from the original? Yes, it is and it does. However, if you are copying only a sub-tree you can't expect that it somehow will include a copy of the whole tree. > It should be indistinguishable from the original and therefore, even > IDREF should also be present. The IDREF I'm dereferencing points to > another book in the same sequence which is there in the copy as well. Right, the book with the ID in question is in the sequence but the root element via which it is logically "connected" to the book with IDREF is not. A copy of a sequence essentially is a collection of sub-trees that are not related to each other. Think of it as a collections of XML documents instead of just one document. You wouldn't expect IDREF in one document to reference ID in another. Boris From boris at codesynthesis.com Thu Oct 30 14:16:49 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:06 2009 Subject: [xsd-users] extending xsd In-Reply-To: <4908D076.5090702@dre.vanderbilt.edu> References: <4908D076.5090702@dre.vanderbilt.edu> Message-ID: <20081030181649.GE20163@karelia> Hi Sumant, Sumant Tambe writes: > In my xsd generator extension, I'm missing child elements of complex > types if the complex type is derived from some other complex type, which > defines the children in question. In that case, what can I do to detect > that a complex type in schema is a derived type of some other type? > Also, how do I get hold of the instance of that base type? You can test it with the inherits_p() function: SemanticGraph::Complex& c = ... if (c.inherits_p ()) { SemanticGraph::Type& base = c.inherits ().base (); } You can see in tree-header.cxx:2287 (3.2.0 source code) how the inheritance of C++ classes is generated. Boris