From stefan.stettler at noser.com Mon Jan 7 10:00:59 2008 From: stefan.stettler at noser.com (stefan.stettler@noser.com) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] XSD and Visual Studio 2005 Integration Message-ID: Hello, I'd like to us XSD in Visual Studio 2005. What's the best way to integrate XSD in the build steps of Visual Studio. I think a custom build step is the solution. Is there an example of such a .rule-File? Thank you and kind regards, /Stefan Stettler noser engineering ag talackerstrasse 99 ch-8404 winterthur +41 52 234 56 33 direkt +41 52 234 56 11 zentrale stefan.stettler@noser.com www.noser.com From boris at codesynthesis.com Tue Jan 8 04:21:16 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] XSD and Visual Studio 2005 Integration In-Reply-To: References: Message-ID: <20080108092116.GA5168@karelia> Hi Stefan, stefan.stettler@noser.com writes: > I'd like to us XSD in Visual Studio 2005. What's the best way to > integrate XSD in the build steps of Visual Studio. > > I think a custom build step is the solution. Yes, a custom build step is what we use in the examples. > Is there an example of such a .rule-File? I just created one for the C++/Tree Mapping: http://www.codesynthesis.com/~boris/tmp/xsd-cxx-tree.rules It provides GUI for the commonly used command line options. Let me know if you experience any problems. Boris From Henry_C.Ngu at lamresearch.com Thu Jan 10 19:25:09 2008 From: Henry_C.Ngu at lamresearch.com (Ngu, Henry C) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] (no subject) Message-ID: <252615686DDBA845977D9AF898D2F9770AF7918F@pdtcexchmbx03.fremont.lamrc.net> Hi: I had encountered error while doing the following xsd cxx-parser --namespace-map urn:semi-org:xsd.E132-1.V0305.auth=auth --namespace-map urn:semi-org:xsd.CommonComponents.V0305.ccs=ccs E134-1-V1105-Schema.xsd Error: D:\workarea\Projects\soap\CppSoapClient\Schemas_Codesynthesis-Semi\E1340 01105>xsd cxx-parser --namespace-map urn:semi-org:xsd.E132-.V0305.auth=auth -namespace -map urn:semi-org:xsd.CommonComponents.V0305.ccs=ccs E134-1-V1105-Schema.xsd E132CommonComponents-V0305-Schema.xsd:12:47: error: element name 'ErrorType/Extension' creates an unstable conflict when used as a type name E134CommonComponents-V0305-Schema.xsd:13:21: info: conflicting type is defined here E132CommonComponents-V0305-Schema.xsd:12:47: info: use --anonymous-regex to resolve this conflict E132CommonComponents-V0305-Schema.xsd:12:47: info: and don't forget to pass the same option when translating 'E132CommonComponents-V0305-Schema.xsd' and all the schemas that refer to it Thanks Henry -------------- next part -------------- A non-text attachment was scrubbed... Name: E132CommonComponents-V0305-Schema.xsd Type: application/octet-stream Size: 1852 bytes Desc: E132CommonComponents-V0305-Schema.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20080110/5ae51750/E132CommonComponents-V0305-Schema.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: E134-1-V1105-Schema.xsd Type: application/octet-stream Size: 32752 bytes Desc: E134-1-V1105-Schema.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20080110/5ae51750/E134-1-V1105-Schema.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: E134CommonComponents-V0305-Schema.xsd Type: application/octet-stream Size: 1852 bytes Desc: E134CommonComponents-V0305-Schema.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20080110/5ae51750/E134CommonComponents-V0305-Schema.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: E132-1-V0305-Schema.xsd Type: application/octet-stream Size: 19525 bytes Desc: E132-1-V0305-Schema.xsd Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20080110/5ae51750/E132-1-V0305-Schema.obj From boris at codesynthesis.com Fri Jan 11 10:22:45 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Unstable conflict error in SEMI schemas In-Reply-To: <252615686DDBA845977D9AF898D2F9770AF7918F@pdtcexchmbx03.fremont.lamrc.net> References: <252615686DDBA845977D9AF898D2F9770AF7918F@pdtcexchmbx03.fremont.lamrc.net> Message-ID: <20080111152245.GA5925@karelia> Hi Henry, In the future please provide a short description of the problem in the subject when posting to this mailing list. As for your question, you have already asked it and I have already provided you with the answer: http://www.codesynthesis.com/pipermail/xsd-users/2007-November/001342.html Boris From boris at codesynthesis.com Tue Jan 15 10:45:53 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] XSD 3.1.0.b1 released Message-ID: <20080115154553.GA19690@karelia> Hi, We have released XSD 3.1.0.b1 which is the first and most likely the final beta for the upcoming 3.1.0 release. The NEWS file entries so far are as follows: * New option, --file-per-type, triggers generation of a separate set of C++ files for each type defined in XML Schema. This compilation mode is primarily useful when some of your schemas cannot be compiled separately or have cyclic dependencies which involve type inheritance. Other new options that are useful in this compilation mode are --type-file-regex, --type-file-regex-trace, and --file-list. See the compiler command line manual (man pages) for more information. * New option, --options-file, allows additional command line options to be provided in files, with one option per line. * New option, --reserved-name, allows inserting additional names with optional replacements to the list of names that should not be used as identifiers. See the compiler command line manual (man pages) for details. * New options, --location-map, --location-regex, and --location-regex-trace, allow re-mapping of schema locations specified in the include and import elements without modifying the schema files. See the compiler command line manual (man pages) for more information. * New option, --guard-prefix, allows specifying a prefix that will be added to generated header inclusion guards. * New option, --file-list, triggers creation of a file with a list of generated C++ files. This option is primarily useful in the file-per-type compilation mode (--file-per-type) to create a list of generated C++ files, for example, as a makefile fragment. Other new options that are useful with --file-list are --file-list-prologue, --file-list-epilogue, and --file-list-delim. See the compiler command line manual (man pages) for more information. * Support for the upcoming Xerces-C++ 3.0.0 release. C++/Tree * New option, --generate-intellisense, triggers generation of workarounds for IntelliSense bugs in Visual Studio 2005 (8.0). When this option is used, the resulting code is slightly more verbose. IntelliSense in Visual Studio 2008 (9.0) does not require these workarounds. Support for IntelliSense in Visual Studio 2003 (7.1) is improved with this option but is still incomplete. * New options, --type-naming and --function-naming, allow one to specify the type and function naming conventions that should be used in the generated code. Supported values for --type-naming are: knr (K&R), ucc (upper-camel-case), and java. Supported values for --function-naming are: knr (K&R), lcc (lower-camel- case), and java. For more information see the NAMING CONVENTION section in the compiler command line manual (man pages). * New options, --type-regex, --accessor-regex, --modifier-regex, --parser-regex, --serializer-regex, and --enumerator-regex, allow one to specify transformations for type, accessor function, modifier function, parsing function, serialization function, and enumerator names in order to produce the generated code using a custom naming convention. For more information see the NAMING CONVENTION section in the compiler command line manual (man pages). * Generated list classes now provide a complete set of constructors and conform to the standard C++ sequence interface. * String-based types now provide two extra constructors that take C string and std::string as their arguments. This allows direct initialization of string-based types from string literals. * New implementations of the XML Schema date/time types (date, dateTime, duration, gDay, gMonth, gMonthDay, gYear, gYearMonth, and time) that represent the information in the numerical form. * Support for customization of anyType. Because anyType is a base type for every generated type, customizing it allows you to implement custom functionality that spans the entire type system. See the comments example in the examples/cxx/tree/custom/ directory. * New option, --omit-default-attributes, triggers generation of extra checks that exclude attributes with default and fixed values from the serialized XML documents. * The parsing functions that used to read from DOMInputSource were changed to use InputSource to ease support for of Xerces-C++ 3 and 2 series in the same code base. C++/Parser * The date/time types (date, dateTime, gDay, gMonth, gMonthDay, gYear, gYearMonth, and time) now represent time zone in the numerical form. Precompiled binary distributions for GNU/Linux x86, Mac OS X x86, and Windows are available from the product's download page: http://www.codesynthesis.com/products/xsd/download.xhtml Source code for this release is available from the project's web page: http://www.codesynthesis.com/projects/xsd/ SHA1 checksums for the files: 25b8230a8c415ba248c6ec5c986d2af426e73962 xsd-3.1.0.b1.tar.bz2 ce4a3cd7598d0f78ee4ccbc41d59b5162927e77b xsd-3.1.0.b1-i686-linux-gnu.tar.bz2 7e730152a2512fe11490721669fb4f75b606f527 xsd-3.1.0.b1-i686-macosx.tar.bz2 c95424631c07f1a6e851579c9939cec123b0d068 xsd-3.1.0.b1-i686-windows.zip Have fun, Boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20080115/695fac37/attachment.pgp From EsbenS at TCElectronic.com Tue Jan 15 12:37:28 2008 From: EsbenS at TCElectronic.com (Esben Skovenborg) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Double trouble In-Reply-To: <20061207152421.GA23270@karelia> References: <20061207152421.GA23270@karelia> Message-ID: Hi, I have a question regarding XSD 3.0 and its serialization of double-precision numbers. My application (the XML requirements of which seem to be elegantly handled by the XSD:) needs to serialize and parse doubles in the full range and precision of 64-bit doubles. A recent thread on xsd-users ("losing double precision in output xml") refers to a patch (xsd-2.3.0-fp-serialization-patch) which indicate that XSD 2.3 mapped the xsd:double into double, but xsd:decimal into long double. In version 3, both xsd types are mapped into double, which apparently forces the serializer to not use exponential notation at all. I note that "We map both xsd:double and xsd:decimal to double and decimal cannot be in scientific notation" (from xsd/cxx/tree/serialization.hxx), however the present solution seems to severely limit the range of the numbers that can be represented. For my application, the printf %g format is essentially what's needed for serializing xsd:double -- hence my quick'n'dirty fix: operator<< (xercesc::DOMElement& e, double d) { char strbuf[32]; sprintf(strbuf, "%.16g", d); std::string s (strbuf); e << s; } Now, I'm not sure if there's a better way of achieving this, or how to have different << operators for the xsd:double and xsd:decimal. Perhaps the long double solution in XSD 2.3 was a pretty good idea after all? Kind regards, Esben From Raymond.Rizzuto at sig.com Tue Jan 15 16:03:27 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] link issues Message-ID: I downloaded the 3.0 version of xsd for windows with the installer package. I set up the include/lib/exe paths for Visual Studio 2005/VC8 up as specified. I am able to compile the example tree code, but get link errors. For example, this is what happens when compiling the hello project: ------ Rebuild All started: Project: hello, Configuration: Debug Win32 ------ Deleting intermediate files and output files for project 'hello', configuration 'Debug|Win32'. xsd hello.xsd Compiling... hello.cxx driver.cxx Generating Code... Linking... hello.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall xercesc_2_7::InputSource::setSystemId(unsigned short const * const)" (?setSystemId@InputSource@xercesc_2_7@@UAEXQBG@Z) hello.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall xercesc_2_7::InputSource::setPublicId(unsigned short const * const)" (?setPublicId@InputSource@xercesc_2_7@@UAEXQBG@Z) hello.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall xercesc_2_7::InputSource::setEncoding(unsigned short const * const)" (?setEncoding@InputSource@xercesc_2_7@@UAEXQBG@Z) hello.obj : error LNK2001: unresolved external symbol "public: virtual unsigned short const * __thiscall xercesc_2_7::InputSource::getSystemId(void)const " (?getSystemId@InputSource@xercesc_2_7@@UBEPBGXZ) hello.obj : error LNK2001: unresolved external symbol "public: virtual unsigned short const * __thiscall xercesc_2_7::InputSource::getPublicId(void)const " (?getPublicId@InputSource@xercesc_2_7@@UBEPBGXZ) hello.obj : error LNK2001: unresolved external symbol "public: virtual unsigned short const * __thiscall xercesc_2_7::InputSource::getEncoding(void)const " (?getEncoding@InputSource@xercesc_2_7@@UBEPBGXZ) hello.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl xercesc_2_7::XMLString::stringLen(unsigned short const * const)" (__imp_?stringLen@XMLString@xercesc_2_7@@SAIQBG@Z) referenced in function "class std::basic_string,class std::allocator > __cdecl xsd::cxx::xml::transcode(unsigned short const *)" (??$transcode@D@xml@cxx@xsd@@YA?AV?$basic_string@DU?$char_traits@D@std@@ V?$allocator@D@2@@std@@PBG@Z) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation" (__imp_?fgXercesSchemaExternalNoNameSpaceSchemaLocation@XMLUni@xercesc_2 _7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesSchemaExternalSchemaLocation" (__imp_?fgXercesSchemaExternalSchemaLocation@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesUserAdoptsDOMDocument" (__imp_?fgXercesUserAdoptsDOMDocument@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesSchemaFullChecking" (__imp_?fgXercesSchemaFullChecking@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesSchema" (__imp_?fgXercesSchema@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMValidation" (__imp_?fgDOMValidation@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMWhitespaceInElementContent" (__imp_?fgDOMWhitespaceInElementContent@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMNamespaces" (__imp_?fgDOMNamespaces@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMEntities" (__imp_?fgDOMEntities@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMDatatypeNormalization" (__imp_?fgDOMDatatypeNormalization@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMComments" (__imp_?fgDOMComments@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class xercesc_2_7::DOMImplementation * __cdecl xercesc_2_7::DOMImplementationRegistry::getDOMImplementation(unsigned short const *)" (__imp_?getDOMImplementation@DOMImplementationRegistry@xercesc_2_7@@SAPA VDOMImplementation@2@PBG@Z) referenced in function "struct xsd::cxx::xml::dom::auto_ptr __cdecl xsd::cxx::xml::dom::parse(class std::basic_string,class std::allocator > const &,class xercesc_2_7::DOMErrorHandler &,class xsd::cxx::xml::properties const &,unsigned long)" (??$parse@D@dom@xml@cxx@xsd@@YA?AU?$auto_ptr@VDOMDocument@xercesc_2_7@@@ 0123@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAV DOMErrorHandler@xercesc_2_7@@ABV?$properties@D@123@K@Z) hello.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) protected: __thiscall xercesc_2_7::InputSource::InputSource(unsigned short const * const,class xercesc_2_7::MemoryManager * const)" (__imp_??0InputSource@xercesc_2_7@@IAE@QBGQAVMemoryManager@1@@Z) referenced in function "public: __thiscall xsd::cxx::xml::sax::std_input_source::std_input_source(class std::basic_istream > &,class std::basic_string,class std::allocator > const &)" (??$?0D@std_input_source@sax@xml@cxx@xsd@@QAE@AAV?$basic_istream@DU?$cha r_traits@D@std@@@std@@ABV?$basic_string@DU?$char_traits@D@std@@V?$alloca tor@D@2@@6@@Z) Debug/driver.exe : fatal error LNK1120: 20 unresolved externals Build log was saved at "file://c:\Program Files\CodeSynthesis XSD 3.0\examples\cxx\tree\hello\Debug\BuildLog.htm" hello - 21 error(s), 0 warning(s) ________________________________ Ray Rizzuto Susqehanna 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 Raymond.Rizzuto at sig.com Tue Jan 15 14:28:19 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] xsd crash Message-ID: Hi! I am running the 3.0 version of XSD against a large, complicated schema that my company developed. I get a lot of warning and info messages, then the application crashes: xsd cxx-tree --root-element-none --root-element OrderInstruction --generate-polymorphic "SDMP-1.1 latest.xsd" SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'ticket' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'ticket' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:587:46: info: element 'ticket' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'currency' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'currency' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:588:33: info: element 'currency' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'priceType' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'priceType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:598:37: info: element 'priceType' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'price' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'price' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:642:51: info: element 'price' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'stopPrice' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'stopPrice' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:647:85: info: element 'stopPrice' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'referencePriceType' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'referencePriceType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:657:65: info: element 'referencePriceType' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'referencePrice' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'referencePrice' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:662:60: info: element 'referencePrice' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'algorithm' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'algorithm' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:670:53: info: element 'algorithm' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'algorithmParameter' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'algorithmParameter' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:675:98: info: element 'algorithmParameter' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'pegText' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'pegText' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:681:80: info: element 'pegText' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'trailingStopText' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'trailingStopText' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:686:89: info: element 'trailingStopText' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'quantityType' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'quantityType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:697:40: info: element 'quantityType' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'quantity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'quantity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:721:36: info: element 'quantity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'minQuantity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'minQuantity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:731:69: info: element 'minQuantity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'maxQuantity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'maxQuantity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:741:69: info: element 'maxQuantity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'referenceQuantityType' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'referenceQuantityType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:756:49: info: element 'referenceQuantityType' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'referenceQuantity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'referenceQuantity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:769:45: info: element 'referenceQuantity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'displayQuantity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'displayQuantity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:782:68: info: element 'displayQuantity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'displayRefreshQuantity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'displayRefreshQuantity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:787:105: info: element 'displayRefreshQuantity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'timeInForceDateTime' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'timeInForceDateTime' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:794:65: info: element 'timeInForceDateTime' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'timeInForceActivationDateTime' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'timeInForceActivationDateTime' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:799:105: info: element 'timeInForceActivationDateTime' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'timeInForceExpirationDateTime' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'timeInForceExpirationDateTime' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:804:105: info: element 'timeInForceExpirationDateTime' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'efpText' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'efpText' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:810:80: info: element 'efpText' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'parentOrderInstructionId' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'parentOrderInstructionId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:815:111: info: element 'parentOrderInstructionId' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'beneficiaryLegalEntity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'beneficiaryLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:820:81: info: element 'beneficiaryLegalEntity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'netOrCommFormula' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'netOrCommFormula' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:825:89: info: element 'netOrCommFormula' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'netOrCommAmount' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'netOrCommAmount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:830:89: info: element 'netOrCommAmount' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'originatorId' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'originatorId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:835:63: info: element 'originatorId' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'handlerId' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'handlerId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:840:74: info: element 'handlerId' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'directedExecutionVenue' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'directedExecutionVenue' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:845:75: info: element 'directedExecutionVenue' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'directedOrderHandlingService' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'directedOrderHandlingService' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:850:96: info: element 'directedOrderHandlingService' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'originatorDesignatedLegalEntity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'originatorDesignatedLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:855:90: info: element 'originatorDesignatedLegalEntity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'originatorTradingPerson' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'originatorTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:860:77: info: element 'originatorTradingPerson' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'originatorLegalEntity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'originatorLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:865:66: info: element 'originatorLegalEntity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'handlerTradingPerson' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'handlerTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:870:74: info: element 'handlerTradingPerson' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'handlerLegalEntity' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'handlerLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:875:63: info: element 'handlerLegalEntity' is defined here SDMP-1.1 latest.xsd:880:90: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:880:90: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'orderInstruction' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'orderInstruction' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1598:42: info: element 'orderInstruction' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'previousOrderInstruction' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'previousOrderInstruction' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1599:64: info: element 'previousOrderInstruction' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'instrument' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'instrument' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1600:35: info: element 'instrument' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'request' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'request' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1343:46: info: element 'request' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'originatorTradingPerson' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'originatorTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1348:77: info: element 'originatorTradingPerson' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'originatorLegalEntity' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'originatorLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1353:66: info: element 'originatorLegalEntity' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'originatorDesignatedLegalEntity' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'originatorDesignatedLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1358:90: info: element 'originatorDesignatedLegalEntity' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'handlerTradingPerson' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'handlerTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1363:74: info: element 'handlerTradingPerson' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'handlerLegalEntity' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'handlerLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1368:63: info: element 'handlerLegalEntity' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'beneficiaryLegalEntity' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'beneficiaryLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1373:81: info: element 'beneficiaryLegalEntity' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'controllerParty' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'controllerParty' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1378:69: info: element 'controllerParty' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'handlerAccount' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'handlerAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1388:42: info: element 'handlerAccount' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'originatorAccount' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'originatorAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1389:59: info: element 'originatorAccount' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'parentOrderId' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'parentOrderId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1396:100: info: element 'parentOrderId' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'settlementDate' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'settlementDate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:495:53: info: element 'settlementDate' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'settlementType' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'settlementType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:500:60: info: element 'settlementType' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'originatorId' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'originatorId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1402:77: info: element 'originatorId' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'handlerId' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'handlerId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1407:74: info: element 'handlerId' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'executionVenue' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'executionVenue' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1412:53: info: element 'executionVenue' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'orderHandlingService' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'orderHandlingService' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1417:74: info: element 'orderHandlingService' is defined here SDMP-1.1 latest.xsd:1605:90: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:1605:90: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'order' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'order' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1647:53: info: element 'order' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'complexOrderType' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'complexOrderType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1648:42: info: element 'complexOrderType' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'request' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'request' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1343:46: info: element 'request' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'originatorTradingPerson' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'originatorTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1348:77: info: element 'originatorTradingPerson' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'originatorLegalEntity' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'originatorLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1353:66: info: element 'originatorLegalEntity' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'originatorDesignatedLegalEntity' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'originatorDesignatedLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1358:90: info: element 'originatorDesignatedLegalEntity' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'handlerTradingPerson' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'handlerTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1363:74: info: element 'handlerTradingPerson' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'handlerLegalEntity' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'handlerLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1368:63: info: element 'handlerLegalEntity' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'beneficiaryLegalEntity' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'beneficiaryLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1373:81: info: element 'beneficiaryLegalEntity' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'controllerParty' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'controllerParty' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1378:69: info: element 'controllerParty' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'handlerAccount' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'handlerAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1388:42: info: element 'handlerAccount' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'originatorAccount' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'originatorAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1389:59: info: element 'originatorAccount' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'parentOrderId' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'parentOrderId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1396:100: info: element 'parentOrderId' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'settlementDate' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'settlementDate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:495:53: info: element 'settlementDate' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'settlementType' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'settlementType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:500:60: info: element 'settlementType' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'originatorId' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'originatorId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1402:77: info: element 'originatorId' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'handlerId' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'handlerId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1407:74: info: element 'handlerId' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'executionVenue' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'executionVenue' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1412:53: info: element 'executionVenue' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'orderHandlingService' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'orderHandlingService' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1417:74: info: element 'orderHandlingService' is defined here SDMP-1.1 latest.xsd:1669:90: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:1669:90: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:1321:91: warning: namespace '##any' allows for element 'locate' SDMP-1.1 latest.xsd:1321:91: warning: generated code may not associate element 'locate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1295:70: info: element 'locate' is defined here SDMP-1.1 latest.xsd:1321:91: warning: namespace '##any' allows for element 'locateExemptionType' SDMP-1.1 latest.xsd:1321:91: warning: generated code may not associate element 'locateExemptionType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1300:74: info: element 'locateExemptionType' is defined here SDMP-1.1 latest.xsd:1321:91: warning: namespace '##any' allows for element 'regRepParty' SDMP-1.1 latest.xsd:1321:91: warning: generated code may not associate element 'regRepParty' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1306:66: info: element 'regRepParty' is defined here SDMP-1.1 latest.xsd:1321:91: warning: namespace '##any' allows for element 'contactBrokerParty' SDMP-1.1 latest.xsd:1321:91: warning: generated code may not associate element 'contactBrokerParty' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1311:73: info: element 'contactBrokerParty' is defined here SDMP-1.1 latest.xsd:1321:91: warning: namespace '##any' allows for element 'branchOrganization' SDMP-1.1 latest.xsd:1321:91: warning: generated code may not associate element 'branchOrganization' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1316:65: info: element 'branchOrganization' is defined here SDMP-1.1 latest.xsd:1321:91: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:1321:91: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:1687:91: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:1687:91: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'handlerFee' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'handlerFee' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1851:62: info: element 'handlerFee' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'handlerRebate' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'handlerRebate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1856:65: info: element 'handlerRebate' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'orderInstructionId' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'orderInstructionId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1861:84: info: element 'orderInstructionId' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'orderId' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'orderId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1866:73: info: element 'orderId' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'executionVenue' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'executionVenue' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1871:54: info: element 'executionVenue' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'orderHandlingService' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'orderHandlingService' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1876:75: info: element 'orderHandlingService' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'originatorAccount' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'originatorAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1881:44: info: element 'originatorAccount' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'handlerAccount' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'handlerAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1882:41: info: element 'handlerAccount' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'originatorDesignatedLegalEntity' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'originatorDesignatedLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1883:77: info: element 'originatorDesignatedLegalEntity' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'originatorTradingPerson' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'originatorTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1888:78: info: element 'originatorTradingPerson' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'originatorLegalEntity' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'originatorLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1893:81: info: element 'originatorLegalEntity' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'handlerTradingPerson' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'handlerTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1898:75: info: element 'handlerTradingPerson' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'handlerLegalEntity' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'handlerLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1903:78: info: element 'handlerLegalEntity' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'handlerDesignatedLegalEntity' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'handlerDesignatedLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1908:74: info: element 'handlerDesignatedLegalEntity' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'currency' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'currency' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1764:33: info: element 'currency' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'instrument' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'instrument' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1769:35: info: element 'instrument' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'settlementDate' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'settlementDate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:495:53: info: element 'settlementDate' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'settlementType' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'settlementType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:500:60: info: element 'settlementType' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'transactionText' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'transactionText' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1775:88: info: element 'transactionText' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'postingPerson' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'postingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1780:67: info: element 'postingPerson' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'postingLegalEntity' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'postingLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1785:63: info: element 'postingLegalEntity' is defined here SDMP-1.1 latest.xsd:1913:91: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:1913:91: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:1967:91: warning: namespace '##any' allows for element 'fromTransactionId' SDMP-1.1 latest.xsd:1967:91: warning: generated code may not associate element 'fromTransactionId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1957:69: info: element 'fromTransactionId' is defined here SDMP-1.1 latest.xsd:1967:91: warning: namespace '##any' allows for element 'toTransactionId' SDMP-1.1 latest.xsd:1967:91: warning: generated code may not associate element 'toTransactionId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1962:67: info: element 'toTransactionId' is defined here SDMP-1.1 latest.xsd:1967:91: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:1967:91: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'executionVenue' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'executionVenue' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2053:54: info: element 'executionVenue' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'buyerTradingPerson' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'buyerTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2058:73: info: element 'buyerTradingPerson' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'buyerLegalEntity' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'buyerLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2063:62: info: element 'buyerLegalEntity' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'sellerTradingPerson' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'sellerTradingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2068:74: info: element 'sellerTradingPerson' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'sellerLegalEntity' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'sellerLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2073:63: info: element 'sellerLegalEntity' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'buyerDesignatedLegalEntity' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'buyerDesignatedLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2078:72: info: element 'buyerDesignatedLegalEntity' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'sellerDesignatedLegalEntity' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'sellerDesignatedLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2083:73: info: element 'sellerDesignatedLegalEntity' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'sellerLocate' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'sellerLocate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2089:54: info: element 'sellerLocate' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'sellerLocateExemptionType' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'sellerLocateExemptionType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2094:80: info: element 'sellerLocateExemptionType' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'buyerAccount' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'buyerAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2100:62: info: element 'buyerAccount' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'sellerAccount' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'sellerAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2105:63: info: element 'sellerAccount' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'currency' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'currency' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1764:33: info: element 'currency' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'instrument' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'instrument' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1769:35: info: element 'instrument' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'settlementDate' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'settlementDate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:495:53: info: element 'settlementDate' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'settlementType' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'settlementType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:500:60: info: element 'settlementType' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'transactionText' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'transactionText' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1775:88: info: element 'transactionText' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'postingPerson' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'postingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1780:67: info: element 'postingPerson' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'postingLegalEntity' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'postingLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1785:63: info: element 'postingLegalEntity' is defined here SDMP-1.1 latest.xsd:2110:91: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:2110:91: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'fromAccount' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'fromAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2153:38: info: element 'fromAccount' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'toAccount' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'toAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2154:36: info: element 'toAccount' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'currency' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'currency' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1764:33: info: element 'currency' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'instrument' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'instrument' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1769:35: info: element 'instrument' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'settlementDate' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'settlementDate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:495:53: info: element 'settlementDate' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'settlementType' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'settlementType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:500:60: info: element 'settlementType' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'transactionText' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'transactionText' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1775:88: info: element 'transactionText' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'postingPerson' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'postingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1780:67: info: element 'postingPerson' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'postingLegalEntity' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'postingLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1785:63: info: element 'postingLegalEntity' is defined here SDMP-1.1 latest.xsd:2155:91: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:2155:91: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'fromAccount' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'fromAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2173:38: info: element 'fromAccount' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'toAccount' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'toAccount' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2174:36: info: element 'toAccount' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'currency' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'currency' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1764:33: info: element 'currency' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'instrument' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'instrument' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1769:35: info: element 'instrument' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'settlementDate' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'settlementDate' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:495:53: info: element 'settlementDate' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'settlementType' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'settlementType' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:500:60: info: element 'settlementType' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'transactionText' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'transactionText' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1775:88: info: element 'transactionText' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'postingPerson' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'postingPerson' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1780:67: info: element 'postingPerson' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'postingLegalEntity' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'postingLegalEntity' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:1785:63: info: element 'postingLegalEntity' is defined here SDMP-1.1 latest.xsd:2175:91: warning: namespace '##any' allows for element 'id' SDMP-1.1 latest.xsd:2175:91: warning: generated code may not associate element 'id' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:563:42: info: element 'id' is defined here SDMP-1.1 latest.xsd:2601:89: warning: namespace '##any' allows for element 'containerId' SDMP-1.1 latest.xsd:2601:89: warning: generated code may not associate element 'containerId' correctly if it appears in place of this wildcard SDMP-1.1 latest.xsd:2596:52: info: element 'containerId' is defined here This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ________________________________ Ray Rizzuto Susqehanna 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 Tue Jan 15 16:20:26 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] link issues In-Reply-To: References: Message-ID: <20080115212026.GA22912@karelia> Hi Raymond, Rizzuto, Raymond writes: > I downloaded the 3.0 version of xsd for windows with the installer > package. I set up the include/lib/exe paths for Visual Studio 2005/VC8 > up as specified. I am able to compile the example tree code, but get > link errors. For example, this is what happens when compiling the hello > project: > > [...] > > hello.obj : error LNK2001: unresolved external symbol "public: virtual > void __thiscall xercesc_2_7::InputSource::setSystemId(unsigned short > const * const)" (?setSystemId@InputSource@xercesc_2_7@@UAEXQBG@Z) Do you use the Xerces-C++ headers/libraries that came with the XSD installer or did you build Xerces-C++ yourself? If you are using Xerces-C++ that came with XSD, then one of the following can cause the above link errors: 1. There is another copy of Xerces-C++ headers and/or libraries present on your system and a wrong library gets linked instead of the one provided by XSD. 2. You have changed how Visual Studio treats the wchar_t type in the hello project. To check that, open the "Project Properties" dialog in the "C/C++ -> Language" tab. By default the XSD example projects have the "Treat wchar_t as Built-in Type" option set to "yes". If you are using your own copy of Xerces-C++ then the most likely cause of these errors is the mismatch of the wchar_t handling options between the Xerces-C++ libraries and the XSD example projects. Boris From Raymond.Rizzuto at sig.com Tue Jan 15 16:23:08 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] RE: link issues Message-ID: My bad - I set up the path for VC8/VS2005, but opened the project with VC7/2003. The link error goes away once I rebuilt under VC8. ________________________________ From: Rizzuto, Raymond Sent: Tuesday, January 15, 2008 4:03 PM To: 'xsd-users@codesynthesis.com' Subject: link issues I downloaded the 3.0 version of xsd for windows with the installer package. I set up the include/lib/exe paths for Visual Studio 2005/VC8 up as specified. I am able to compile the example tree code, but get link errors. For example, this is what happens when compiling the hello project: ------ Rebuild All started: Project: hello, Configuration: Debug Win32 ------ Deleting intermediate files and output files for project 'hello', configuration 'Debug|Win32'. xsd hello.xsd Compiling... hello.cxx driver.cxx Generating Code... Linking... hello.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall xercesc_2_7::InputSource::setSystemId(unsigned short const * const)" (?setSystemId@InputSource@xercesc_2_7@@UAEXQBG@Z) hello.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall xercesc_2_7::InputSource::setPublicId(unsigned short const * const)" (?setPublicId@InputSource@xercesc_2_7@@UAEXQBG@Z) hello.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall xercesc_2_7::InputSource::setEncoding(unsigned short const * const)" (?setEncoding@InputSource@xercesc_2_7@@UAEXQBG@Z) hello.obj : error LNK2001: unresolved external symbol "public: virtual unsigned short const * __thiscall xercesc_2_7::InputSource::getSystemId(void)const " (?getSystemId@InputSource@xercesc_2_7@@UBEPBGXZ) hello.obj : error LNK2001: unresolved external symbol "public: virtual unsigned short const * __thiscall xercesc_2_7::InputSource::getPublicId(void)const " (?getPublicId@InputSource@xercesc_2_7@@UBEPBGXZ) hello.obj : error LNK2001: unresolved external symbol "public: virtual unsigned short const * __thiscall xercesc_2_7::InputSource::getEncoding(void)const " (?getEncoding@InputSource@xercesc_2_7@@UBEPBGXZ) hello.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl xercesc_2_7::XMLString::stringLen(unsigned short const * const)" (__imp_?stringLen@XMLString@xercesc_2_7@@SAIQBG@Z) referenced in function "class std::basic_string,class std::allocator > __cdecl xsd::cxx::xml::transcode(unsigned short const *)" (??$transcode@D@xml@cxx@xsd@@YA?AV?$basic_string@DU?$char_traits@D@std@@ V?$allocator@D@2@@std@@PBG@Z) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation" (__imp_?fgXercesSchemaExternalNoNameSpaceSchemaLocation@XMLUni@xercesc_2 _7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesSchemaExternalSchemaLocation" (__imp_?fgXercesSchemaExternalSchemaLocation@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesUserAdoptsDOMDocument" (__imp_?fgXercesUserAdoptsDOMDocument@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesSchemaFullChecking" (__imp_?fgXercesSchemaFullChecking@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgXercesSchema" (__imp_?fgXercesSchema@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMValidation" (__imp_?fgDOMValidation@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMWhitespaceInElementContent" (__imp_?fgDOMWhitespaceInElementContent@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMNamespaces" (__imp_?fgDOMNamespaces@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMEntities" (__imp_?fgDOMEntities@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMDatatypeNormalization" (__imp_?fgDOMDatatypeNormalization@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned short const * const xercesc_2_7::XMLUni::fgDOMComments" (__imp_?fgDOMComments@XMLUni@xercesc_2_7@@2QBGB) hello.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class xercesc_2_7::DOMImplementation * __cdecl xercesc_2_7::DOMImplementationRegistry::getDOMImplementation(unsigned short const *)" (__imp_?getDOMImplementation@DOMImplementationRegistry@xercesc_2_7@@SAPA VDOMImplementation@2@PBG@Z) referenced in function "struct xsd::cxx::xml::dom::auto_ptr __cdecl xsd::cxx::xml::dom::parse(class std::basic_string,class std::allocator > const &,class xercesc_2_7::DOMErrorHandler &,class xsd::cxx::xml::properties const &,unsigned long)" (??$parse@D@dom@xml@cxx@xsd@@YA?AU?$auto_ptr@VDOMDocument@xercesc_2_7@@@ 0123@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAV DOMErrorHandler@xercesc_2_7@@ABV?$properties@D@123@K@Z) hello.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) protected: __thiscall xercesc_2_7::InputSource::InputSource(unsigned short const * const,class xercesc_2_7::MemoryManager * const)" (__imp_??0InputSource@xercesc_2_7@@IAE@QBGQAVMemoryManager@1@@Z) referenced in function "public: __thiscall xsd::cxx::xml::sax::std_input_source::std_input_source(class std::basic_istream > &,class std::basic_string,class std::allocator > const &)" (??$?0D@std_input_source@sax@xml@cxx@xsd@@QAE@AAV?$basic_istream@DU?$cha r_traits@D@std@@@std@@ABV?$basic_string@DU?$char_traits@D@std@@V?$alloca tor@D@2@@6@@Z) Debug/driver.exe : fatal error LNK1120: 20 unresolved externals Build log was saved at "file://c:\Program Files\CodeSynthesis XSD 3.0\examples\cxx\tree\hello\Debug\BuildLog.htm" hello - 21 error(s), 0 warning(s) ________________________________ Ray Rizzuto Susqehanna 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 Tue Jan 15 16:30:48 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] xsd crash In-Reply-To: References: Message-ID: <20080115213048.GB22912@karelia> Hi Raymond, Rizzuto, Raymond writes: > I am running the 3.0 version of XSD against a large, complicated schema > that my company developed. I get a lot of warning and info messages, > then the application crashes: > > xsd cxx-tree --root-element-none --root-element OrderInstruction > --generate-polymorphic "SDMP-1.1 latest.xsd" I am pretty sure the cause of the crash is the space in your schema's file name. I just tried it on a simple schema with a space in its name and the compiler crashes. Can you maybe get rid of the space and see if it works. If it still doesn't then we will need your schema (you can send it privately to me) or a reproducible test case to figure out what's going on. We will also try to fix the "space in file name" bug for the next version of XSD. Thanks for reporting this! Boris From Raymond.Rizzuto at sig.com Tue Jan 15 16:51:42 2008 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] link issues In-Reply-To: <20080115212026.GA22912@karelia> References: <20080115212026.GA22912@karelia> Message-ID: The space in the file name was the issue! Thanks. I was afraid the schema was too complicated. Glad that isn't the case - now I can start using the generated code. -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, January 15, 2008 4:20 PM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] link issues Hi Raymond, Rizzuto, Raymond writes: > I downloaded the 3.0 version of xsd for windows with the installer > package. I set up the include/lib/exe paths for Visual Studio 2005/VC8 > up as specified. I am able to compile the example tree code, but get > link errors. For example, this is what happens when compiling the hello > project: > > [...] > > hello.obj : error LNK2001: unresolved external symbol "public: virtual > void __thiscall xercesc_2_7::InputSource::setSystemId(unsigned short > const * const)" (?setSystemId@InputSource@xercesc_2_7@@UAEXQBG@Z) Do you use the Xerces-C++ headers/libraries that came with the XSD installer or did you build Xerces-C++ yourself? If you are using Xerces-C++ that came with XSD, then one of the following can cause the above link errors: 1. There is another copy of Xerces-C++ headers and/or libraries present on your system and a wrong library gets linked instead of the one provided by XSD. 2. You have changed how Visual Studio treats the wchar_t type in the hello project. To check that, open the "Project Properties" dialog in the "C/C++ -> Language" tab. By default the XSD example projects have the "Treat wchar_t as Built-in Type" option set to "yes". If you are using your own copy of Xerces-C++ then the most likely cause of these errors is the mismatch of the wchar_t handling options between the Xerces-C++ libraries and the XSD example projects. 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 Wed Jan 16 04:01:04 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Double trouble In-Reply-To: References: <20061207152421.GA23270@karelia> Message-ID: <20080116090104.GB26706@karelia> Hi Esben, Esben Skovenborg writes: > Now, I'm not sure if there's a better way of achieving this, or how to > have different << operators for the xsd:double and xsd:decimal. Perhaps > the long double solution in XSD 2.3 was a pretty good idea after all? The problem with long double is that its support and size varies from compiler to compiler and from platform to platform. As a result, several compilers issued warning in that regard. One way to solve the problem you've mentioned above without changing the libxsd runtime would be to re-map (using type customization) xsd:double to some other type, for example long double and to provide custom parsing/serialization code which will use scientific notation. I can elaborate on how to do this if you are interested in this approach. An even better solution would be to re-map xsd:decimal to long double and somehow change parsing and serialization code for xsd:double to use scientific notation. This is not possible right now because the parsing/serialization code for fundamental types is always included into the generated code even if the type was customized. This can be fixed by splitting the parsing/serialization code into separate files for each fundamental type and including them individually only when the corresponding type is not customized. This way you will be able to re-map xsd:double to double and xsd:decimal to long double and to provide your own parsing and serialization code for these types. If you are interested, we can implement this and build you a pre-release binary. Boris From boris at codesynthesis.com Wed Jan 16 04:54:43 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] IntelliSense testing needed Message-ID: <20080116095443.GE26706@karelia> Hi, There has been a number of reports that IntelliSense in Visual Studio 2005 (8.0) does not work on the code generated by the C++/Tree mapping. For the upcoming 3.1.0 release we have added a new option, --generate-intellisense, which triggers generation of workarounds for bugs in Visual Studio 2005 IntelliSense. The resulting code is a bit more verbose but otherwise semantically equivalent to the one generated without this option. Visual Studio 2008 (9.0) appears to have all these bugs fixed, so these workarounds are not required. IntelliSense in Visual Studio 2003 (7.1) will benefit from these workarounds though the support is not complete (IntelliSense in this version is just too buggy). While we have tested the new IntelliSense support on examples and other tests, it would be great if folks who are interested in using IntelliSense in their development tried the just-release 3.1.0.b1 beta with the new option on their projects. The beta can be downloaded from here: http://www.codesynthesis.com/products/xsd/download.xhtml The announcement for the beta is here: http://www.codesynthesis.com/pipermail/xsd-announcements/2008/000025.html Thanks, Boris From jnw at xs4all.nl Wed Jan 16 14:46:31 2008 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] XSD 3.1.0.b1 released Message-ID: <18619.194.109.230.85.1200512791.squirrel@webmail.xs4all.nl> Boris Kolpackov wrote: > We have released XSD 3.1.0.b1 which is the first and most likely the > final beta for the upcoming 3.1.0 release. The NEWS file entries so > far are as follows: [snip] I tried this beta with my work on xml-base[1,2], and stumbled upon a problem in one implementation, custom-xmlbase. This problem is not present in XSD 3.1.0.a3. The problem is in implementation custom-xmlbase[1, item 3], and appears as: custom-xmlbase: /home/bahco/Sandbox/xsd-3.1.0.b1-i686-linux-gnu/libxsd/xsd/cxx/tree/elements.hxx:253: virtual void xsd::cxx::tree::_type::_container(xsd::cxx::tree::type*): Assertion `container_ == 0' failed. This is called indirectly from this statement at line 57 in file custom-xmlbase/xml-base.cpp: this->base (r); The statement immediatelly before is my adaptation from the code generated for implementation explicit[1, top left]: ::std::auto_ptr< base_type > r ( base_traits::create (i, f, this)); into ::std::auto_ptr< base::type > r ( base::traits::create (i, f, &type)); All other implementations worked as expected. This includes the problem described in http://codesynthesis.com/pipermail/xsd-users/2007-December/001418.html which you may have missed due to the holidays. :) Jeroen. [1] http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/index.html [2] http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/parser.html From EsbenS at TCElectronic.com Wed Jan 16 15:46:37 2008 From: EsbenS at TCElectronic.com (Esben Skovenborg) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] XSD 3.1.0.b1 released In-Reply-To: <20080115154553.GA19690@karelia> References: <20080115154553.GA19690@karelia> Message-ID: Hi, Here are 2 comments, after upgrading from XSD 3.0.0 to the 3.1.0.b1 version. > * New option, --generate-intellisense, triggers generation of workarounds > for IntelliSense bugs in Visual Studio 2005 (8.0). When this option is > used, the resulting code is slightly more verbose. IntelliSense in > Visual Studio 2008 (9.0) does not require these workarounds. Support > for IntelliSense in Visual Studio 2003 (7.1) is improved with this > option but is still incomplete. This works great for me, in a number of places where IntelliSense would previously give up. I'm using Visual Studio 2005 SP1. > * New implementations of the XML Schema date/time types (date, dateTime, > duration, gDay, gMonth, gMonthDay, gYear, gYearMonth, and time) that > represent the information in the numerical form. In XSD 3.0 I would create an xml_schema::date_time object, corresponding to an xs:dateTime attribute, using a constructor with only a std::string as argument. This constructor seems to have disappeared in the new implementation? So how do I transform a string such as "2008-01-16T18:06:33" into a date_time object? Cheers, Esben From boris at codesynthesis.com Thu Jan 17 03:08:39 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] XSD 3.1.0.b1 released In-Reply-To: References: <20080115154553.GA19690@karelia> Message-ID: <20080117080839.GA5224@karelia> Hi Esben, Esben Skovenborg writes: > This works great for me, in a number of places where IntelliSense would > previously give up. I'm using Visual Studio 2005 SP1. Great, thanks for testing and letting us know! > > * New implementations of the XML Schema date/time types (date, > > dateTime, duration, gDay, gMonth, gMonthDay, gYear, gYearMonth, > > and time) that represent the information in the numerical form. > > In XSD 3.0 I would create an xml_schema::date_time object, corresponding > to an xs:dateTime attribute, using a constructor with only a std::string > as argument. This constructor seems to have disappeared in the new > implementation? So how do I transform a string such as > "2008-01-16T18:06:33" into a date_time object? You would simply use the numerical notation: xml_schema::date_time dt (2008, 1, 16, 18, 6, 33); The new date/time types are documented in the C++/Tree Mapping User Manual in Sections 2.5.7-2.5.16. The manual can be found in the documentation/cxx/tree/manual/ directory in the beta distribution. Boris From boris at codesynthesis.com Thu Jan 17 03:33:21 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] XSD 3.1.0.b1 released In-Reply-To: <18619.194.109.230.85.1200512791.squirrel@webmail.xs4all.nl> References: <18619.194.109.230.85.1200512791.squirrel@webmail.xs4all.nl> Message-ID: <20080117083321.GB5224@karelia> Hi Jeroen, Thanks for testing the beta. Jeroen N. Witmond [Bahco] writes: > The problem is in implementation custom-xmlbase[1, item 3], and appears as: > custom-xmlbase: > xsd-3.1.0.b1-i686-linux-gnu/libxsd/xsd/cxx/tree/elements.hxx:253: > virtual void xsd::cxx::tree::_type::_container(xsd::cxx::tree::type*): > Assertion `container_ == 0' failed. You need to change: xml_base::xml_base(::xsd::cxx::tree::type& type, ::xml_schema::flags f) { in xml-base.cpp to read: xml_base::xml_base(::xsd::cxx::tree::type& type, ::xml_schema::flags f) : _xsd_base_ (f, &type) { > All other implementations worked as expected. This includes the problem > described in > http://codesynthesis.com/pipermail/xsd-users/2007-December/001418.html > which you may have missed due to the holidays. :) Sorry, I haven't had a chance to reply to that email yet. Which problem are you refering to that is fixed in this beta? Thanks, Boris From EsbenS at TCElectronic.com Thu Jan 17 07:07:48 2008 From: EsbenS at TCElectronic.com (Esben Skovenborg) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Double trouble In-Reply-To: <20080116090104.GB26706@karelia> References: <20061207152421.GA23270@karelia> <20080116090104.GB26706@karelia> Message-ID: Hi Boris, Thanks for your quick reply. Although my operator<< hack does solve my immediate problem, I would prefer not to have to patch the libxml runtime. I think it would be most natural to map xsd:double to C++ double, as in your "even better solution", below. What would I need to do? A related issue is the handling of +/-INF and NaN 'special values' of xsd:double elements (http://www.w3.org/TR/xmlschema-2/#double). Will these values be supported by the XSD 3.1 serializer? and by the parser? Cheers, Esben -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, January 16, 2008 10:01 AM To: Esben Skovenborg Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Double trouble Hi Esben, Esben Skovenborg writes: > Now, I'm not sure if there's a better way of achieving this, or how to > have different << operators for the xsd:double and xsd:decimal. > Perhaps the long double solution in XSD 2.3 was a pretty good idea after all? The problem with long double is that its support and size varies from compiler to compiler and from platform to platform. As a result, several compilers issued warning in that regard. One way to solve the problem you've mentioned above without changing the libxsd runtime would be to re-map (using type customization) xsd:double to some other type, for example long double and to provide custom parsing/serialization code which will use scientific notation. I can elaborate on how to do this if you are interested in this approach. An even better solution would be to re-map xsd:decimal to long double and somehow change parsing and serialization code for xsd:double to use scientific notation. This is not possible right now because the parsing/serialization code for fundamental types is always included into the generated code even if the type was customized. This can be fixed by splitting the parsing/serialization code into separate files for each fundamental type and including them individually only when the corresponding type is not customized. This way you will be able to re-map xsd:double to double and xsd:decimal to long double and to provide your own parsing and serialization code for these types. If you are interested, we can implement this and build you a pre-release binary. Boris From jnw at xs4all.nl Thu Jan 17 12:10:02 2008 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Double trouble Message-ID: <17460.194.109.230.85.1200589802.squirrel@webmail.xs4all.nl> Greetings, all! What seems to me to be a nice project is to write a custom integer type for xsd that is a wrapper for the GNU Multiple Precision Arithmetic Library[1]. It also has C++ bindings. Unfortunately, it may very well be years before I get to actually do something about it. :) Jeroen. [1] http://gmplib.org/ Related Debian packages are libgmp3c2 and libgmpxx4. Esben Skovenborg wrote: > Hi Boris, > > Thanks for your quick reply. > > Although my operator<< hack does solve my immediate problem, I would > prefer not to have to patch the libxml runtime. > I think it would be most natural to map xsd:double to C++ double, as in > your "even better solution", below. What would I need to do? > > A related issue is the handling of +/-INF and NaN 'special values' of > xsd:double elements (http://www.w3.org/TR/xmlschema-2/#double). Will > these values be supported by the XSD 3.1 serializer? and by the parser? > > > Cheers, > > Esben > > > -----Original Message----- > From: Boris Kolpackov [mailto:boris@codesynthesis.com] > Sent: Wednesday, January 16, 2008 10:01 AM > To: Esben Skovenborg > Cc: xsd-users@codesynthesis.com > Subject: Re: [xsd-users] Double trouble > > Hi Esben, > > Esben Skovenborg writes: > >> Now, I'm not sure if there's a better way of achieving this, or how to > >> have different << operators for the xsd:double and xsd:decimal. >> Perhaps the long double solution in XSD 2.3 was a pretty good idea > after all? > > The problem with long double is that its support and size varies from > compiler to compiler and from platform to platform. As a result, several > compilers issued warning in that regard. > > One way to solve the problem you've mentioned above without changing the > libxsd runtime would be to re-map (using type customization) xsd:double > to some other type, for example long double and to provide custom > parsing/serialization code which will use scientific notation. > I can elaborate on how to do this if you are interested in this > approach. > > An even better solution would be to re-map xsd:decimal to long double > and somehow change parsing and serialization code for xsd:double to use > scientific notation. This is not possible right now because the > parsing/serialization code for fundamental types is always included into > the generated code even if the type was customized. This can be fixed by > splitting the parsing/serialization code into separate files for each > fundamental type and including them individually only when the > corresponding type is not customized. This way you will be able to > re-map xsd:double to double and xsd:decimal to long double and to > provide your own parsing and serialization code for these types. If you > are interested, we can implement this and build you a pre-release > binary. > > Boris > > > > From jnw at xs4all.nl Thu Jan 17 13:03:29 2008 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] XSD 3.1.0.b1 released Message-ID: <9189.194.109.230.85.1200593009.squirrel@webmail.xs4all.nl> Boris Kolpackov wrote: > Jeroen N. Witmond [Bahco] writes: > >> The problem is in implementation custom-xmlbase[1, item 3], and appears >> as: >> custom-xmlbase: >> xsd-3.1.0.b1-i686-linux-gnu/libxsd/xsd/cxx/tree/elements.hxx:253: >> virtual void xsd::cxx::tree::_type::_container(xsd::cxx::tree::type*): >> Assertion `container_ == 0' failed. > > You need to change: > > xml_base::xml_base(::xsd::cxx::tree::type& type, > ::xml_schema::flags f) > { > > in xml-base.cpp to read: > > xml_base::xml_base(::xsd::cxx::tree::type& type, > ::xml_schema::flags f) > : _xsd_base_ (f, &type) > { > Thanks! >> All other implementations worked as expected. This includes the problem >> described in >> http://codesynthesis.com/pipermail/xsd-users/2007-December/001418.html >> which you may have missed due to the holidays. :) > > Sorry, I haven't had a chance to reply to that email yet. Which problem > are you refering to that is fixed in this beta? Sorry to say that, as I had not seen a reply, I expected the problem (in item 5 in that email) still to be present in version 3.1.0.b1, and it was. In summary, when I throw an exception in the constructor of a custom type, the DOMDocument is reset twice. To demonstrate the problem, you can run my implementation named custom-datamodel. This requires version 3.1.0.a1 or later of xsd. The problem is also present in versions 3.1.0.a1 and 3.1.0.a3. Jeroen. From boris at codesynthesis.com Sun Jan 20 03:57:17 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Double trouble In-Reply-To: References: <20061207152421.GA23270@karelia> <20080116090104.GB26706@karelia> Message-ID: <20080120085717.GA18917@karelia> Hi Esben, Esben Skovenborg writes: > I think it would be most natural to map xsd:double to C++ double, as in > your "even better solution", below. What would I need to do? Ok, I've added the necessary support to the compiler. The pre-release binary is here (I assumed you are using Windows): http://www.codesynthesis.com/~boris/tmp/xsd-3.1.0.b2-i686-windows.zip I've also create an example that shows how to re-map xsd:double and xsd:decimal: http://www.codesynthesis.com/~boris/tmp/custom-double.zip It implements serialization of xsd:double in scientific notation. There is the README file that explains what's going on. When adopting to your application, you would replace test.xsd with your own schema and change the code in *-parsing.hxx and *-serialization.hxx if necessary (e.g., you may want to set your own precisions, etc.). > A related issue is the handling of +/-INF and NaN 'special values' of > xsd:double elements (http://www.w3.org/TR/xmlschema-2/#double). Will > these values be supported by the XSD 3.1 serializer? and by the parser? Yes, they are supported by the pre-release and the custom-double example. Boris From boris at codesynthesis.com Sun Jan 20 05:12:52 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] cxx-parser: Not all attributes in the XML namespace are typemapped. In-Reply-To: <6785.194.109.230.85.1199118719.squirrel@webmail.xs4all.nl> References: <6785.194.109.230.85.1199118719.squirrel@webmail.xs4all.nl> Message-ID: <20080120101252.GB18917@karelia> Hi Jeroen, Jeroen N. Witmond [Bahco] writes: > All this also resulted in a number of questions and comments: > > 1. The generated test driver for parser-datamodel contains, under '// > Instantiate individual parsers.', the declaration > '::xml_schema::ncname_pimpl ncname_p;'. This variable ncname_p is never > used. This is a bug and it is now fixed for 3.1.0. > 2. It would be nice if cxx-parser supported the --generate-xml-schema and > --extern-xml-schema like cxx-tree. I've added this to my TODO list though it probably won't be implemented for 3.1.0. > 3. In the handler for xml:id, I throw an exception when the value of the > attribute has been seen before. Is there a way to include information > about the source location in the xml file in this exception? There is no easy way to get this information at the moment. However, we are planning to change the underlying C++/Parser architecture which would also allow accessing the underlying XML parser from parser implementations which in turn would allow you to query line/column information. This change is not planned for 3.1.0 though. The "hard" way that will work right now is to set the SAX parser yourself and route the low-level parsing events to the document object (see libxsd/xsd/cxx/parser/document.hxx). When an exception is thrown by one of the parser implementations, you can catch it at the point where you set up the SAX parser, query the line/column information, add it to the exception, and re-throw. > 4. To handle the inheritance for an element, I need access to the parent > of that element. At the moment, I use an ugly hack for this, see file > custom-datamodel/XmlNamespace.cpp[4], starting at line 146. Is there a > better way to do this? I am having a hard time following your code, but if I understood you correctly, you need to get hold of a object model node that contains this instance. If that's the case then you can use _me->_container(). > 5. When I throw an exception in the setter for xml:id (called from the > constructor of the custom type), the program terminates with > pure virtual method called > terminate called without an active exception > Debugging with Valgrind[4] shows that the DOMDocument is reset twice. This appears to be a bug. I've added it to my TODO list. > 6. As in the case of cxx-parser, it would be nice if I could report the > source location in the xml file also with cxx-tree. Please see this thread for more information on how to do this: http://www.codesynthesis.com/pipermail/xsd-users/2007-June/001080.html Thanks for all the bug report! Boris From jnw at xs4all.nl Sun Jan 20 10:17:26 2008 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] cxx-parser: Not all attributes in the XML namespace are typemapped. Message-ID: <4871.194.109.230.85.1200842246.squirrel@webmail.xs4all.nl> Hi Boris, Boris Kolpackov wrote: > Jeroen N. Witmond [Bahco] writes: > >> All this also resulted in a number of questions and comments: >> >> 1. The generated test driver for parser-datamodel contains, under '// >> Instantiate individual parsers.', the declaration >> '::xml_schema::ncname_pimpl ncname_p;'. This variable ncname_p is never >> used. > > This is a bug and it is now fixed for 3.1.0. I assume you mean it is fixed afer 3.1.0.b1. >> 4. To handle the inheritance for an element, I need access to the parent >> of that element. At the moment, I use an ugly hack for this, see file >> custom-datamodel/XmlNamespace.cpp[4], starting at line 146. Is there a >> better way to do this? > > I am having a hard time following your code, but if I understood you > correctly, you need to get hold of a object model node that contains > this instance. If that's the case then you can use _me->_container(). You are right, that is what I need, and my code was an ugly hack. >> 5. When I throw an exception in the setter for xml:id (called from the >> constructor of the custom type), the program terminates with >> pure virtual method called >> terminate called without an active exception >> Debugging with Valgrind[4] shows that the DOMDocument is reset twice. > > This appears to be a bug. I've added it to my TODO list. I've fixed this bug by making the following change in the generated code: --- lax.cxx 2008-01-20 13:14:32.000000000 +0100 +++ lax.cpp 2008-01-20 16:01:42.000000000 +0100 @@ -400,18 +400,15 @@ ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d ( ::xsd::cxx::xml::dom::parse< char > (u, h, p, f)); h.throw_if_failed< ::xsd::cxx::tree::parsing< char > > (); ::std::auto_ptr< ::metadox::foo_type > r ( ::metadox::foo ( - d.get (), f | ::xml_schema::flags::own_dom, p)); - - if (f & ::xml_schema::flags::keep_dom) - d.release (); + d.release (), f | ::xml_schema::flags::own_dom, p)); return r; } ::std::auto_ptr< ::metadox::foo_type > foo (const ::std::string& u, ::xml_schema::error_handler& h, > Thanks for all the bug report! You're welcome! Jeroen. From boris at codesynthesis.com Mon Jan 21 02:39:56 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Re: In-memory validation In-Reply-To: References: <20070925172403.GD5265@karelia> Message-ID: <20080121073956.GB29391@karelia> Hi David, After some more thinking and experimentation on the subject of in- memory validation I would like to get your thoughts on our current view of how it can be implemented and whether it will still be useful for you project. You initial use-case (quoted below) calls for what I would call "immediate detection" of validation errors. Based on this notion of immediate detection, we can place every XML Schema validation construct (e.g., maxOccurs/minOccurs, ordering of elements, facets, uniqueness, etc.) into one of the three categories: 1. Desirable and possible/efficient to implement 2. Desirable and impossible/inefficient to implement 3. Undesirable Into the "desirable and possible/efficient" category fall, for example, the enforcement of xsd:ID uniqueness constraint as well as maxOccurs and the maxLength list facet. The "desirable and impossible/inefficient" category contains the bulk of the XML Schema validation constructs. These include most of the facets and key/keyref/unique constructs. Let's consider the minInclusive and maxInclusive facets from your example below. The range checking code will have to be called after every modification to the underlying int value. In the current architecture you can do, for example, the following: int& i = rt->bounded_int(); // Get a reference to the "base" type (int) i = 100; // Impossible to detect. This is an example of a check that is impossible to implement in the current C++/Tree architecture. A check that is possible but inefficient to implement is, for example, the pattern facet on xsd:string. The pattern checking code (most likely a virtual function with quite an expensive body) will have to be called every time a modification is made to any single character in the underlying string. Then there is a number of undesirable checks that, if enforced immediately, would make the object model very awkward to use. These are minOccurs, the length and minLength list facets, ordering of elements, as well as compound keys in key/unique. The problem with all these constraints is that you may need to perform several operations (e.g., several push_back's for minOccurs and element ordering or modification of several elements/attributes for compound key/unique) before the resulting object model becomes valid. Based on these considerations, it appears that while the "immediate detection" model may look appealing on the surface, in reality it is either not practical or undesirable for the majority of XML Schema constructs. This brings us to the next option: "on-demand detection". The idea is that each generated class will have the validate() function which can be called to detect validation errors on a fragment of object model: rt->bounded_int( 50 ); rt->restricted_string( "abc" ); rt->validate (); // Exception is thrown if invalid. There is, however, a number of questions about practical usefulness and implementation of this model: 1. How to point to the error location? Possible options: (1) a reference to the invalid node passed as xml_schema::type& (drawback: hard to know the actual type and thus to do anything about the error), (2) XPath identifying the error location (drawback: impossible to use to correct the error). 2. Some errors may be impossible for the application to correct. For example, if an error indicates that a string does not match a pattern, what is the application going to do? 3. If error correction by the application is hard/impossible then what is the use of in-memory validation other then to know whether the object model is valid/invalid? I would therefore appreciate any feedback on these concerns as well as on what people expect from the in-memory validation facility in their applications. Thanks, Boris david.r.moss@selex-comms.com writes: > A while ago there was talk of in-memory validation as outlined in an > example below. > > Example code: > > // Load will fail when content is invalid. > auto_ptr rt( root( "in-memory-validation-test.xml" ) ); > > // Modify with a valid value (range is 20-80 inclusive). > rt->bounded_int( 50 ); > cout << *rt << endl; > > rt->bounded_int( 100 ); // Ideally, this should fail (throw exception - as > initial file load would) > cout << *rt << endl; > > > I believe this kind of capability was on your 'to do' list at one point; > is this still the case and, if so, do you have an idea of time-scales?! > > Cheers, > Dave. From boris at codesynthesis.com Mon Jan 21 03:16:57 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] cxx-parser: Not all attributes in the XML namespace are typemapped. In-Reply-To: <4871.194.109.230.85.1200842246.squirrel@webmail.xs4all.nl> References: <4871.194.109.230.85.1200842246.squirrel@webmail.xs4all.nl> Message-ID: <20080121081657.GD29391@karelia> Hi Jeroen, Jeroen N. Witmond [Bahco] writes: > > This is a bug and it is now fixed for 3.1.0. > > I assume you mean it is fixed afer 3.1.0.b1. Right, the fix will be in the 3.1.0 final release. > I've fixed this bug by making the following change in the generated code: > --- lax.cxx 2008-01-20 13:14:32.000000000 +0100 > +++ lax.cpp 2008-01-20 16:01:42.000000000 +0100 > @@ -400,18 +400,15 @@ > ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d ( > ::xsd::cxx::xml::dom::parse< char > (u, h, p, f)); > > h.throw_if_failed< ::xsd::cxx::tree::parsing< char > > (); > > ::std::auto_ptr< ::metadox::foo_type > r ( > ::metadox::foo ( > - d.get (), f | ::xml_schema::flags::own_dom, p)); > - > - if (f & ::xml_schema::flags::keep_dom) > - d.release (); > + d.release (), f | ::xml_schema::flags::own_dom, p)); > > return r; > } > > ::std::auto_ptr< ::metadox::foo_type > > foo (const ::std::string& u, > ::xml_schema::error_handler& h, The problem with this fix is that it will result in a memory leak if an exception is thrown from metadox::foo before the constructor for the root type is called. This will happen, for example, if the root element in the document does not match that expected by the parsing function. In normal circumstances this kind of problem is address by passing an automatic pointer (e.g., dom::auto_ptr) which is reset at the point where the new object assumes ownership of the resource. In our case, we pass a root element to the constructor and depending on the flag (keep_dom), the constructor also assumes ownership of the document. An ugly, but workable solution would be to pass a pointer to the dom::auto_ptr as user data attached to the document. This way the root type constructor can reset auto_ptr when it assumes ownership. Let me know if you have a better idea ;-). Boris From olivier.tournaire at gmail.com Mon Jan 21 19:33:33 2008 From: olivier.tournaire at gmail.com (Olivier Tournaire) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Help on parsing GML Message-ID: <479539DD.5090601@gmail.com> Hi all, I was looking for a C++ librairy to parse GML files, and, instead, I found XSD. This is great ! I already have generating the code from GML schemas, and now, I woul like to parse a simple file. First, as I am not familiar with GML, I would like to have a small sample with, for example, only points. Could you help me ? Then, xsd cxx-tree generated a lot of C++ classes, and I do not know where to begin. What object do I have to declare in order to parse a GML file ? Any help would be appreciated. Best regards Olivier Tournaire From boris at codesynthesis.com Tue Jan 22 02:12:16 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Help on parsing GML In-Reply-To: <479539DD.5090601@gmail.com> References: <479539DD.5090601@gmail.com> Message-ID: <20080122071216.GA5692@karelia> Hi Olivier, Olivier Tournaire writes: > First, as I am not familiar with GML, I would like to have a small > sample with, for example, only points. Could you help me ? A better place to look for GML document samples would be on the GML publisher's website: http://www.opengeospatial.org/ They also have a forum dedicated to GML where you can ask GML-related questions. > Then, xsd cxx-tree generated a lot of C++ classes, and I do not know > where to begin. What object do I have to declare in order to parse a GML > file? First, I strongly recommend that you read through the C++/Tree Mapping Getting Started Guide: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/ This should give you an idea on how to parser and access GML documents. Generally, you would first identify the document's root element by looking at your sample documents (let's say it is called 'root'). Then you would look for a declaration of this element in the schema and determine its type (let's say it is 'type'). Based on this information you can then write: auto_ptr r = root ("sample.xml"); Boris From EsbenS at TCElectronic.com Tue Jan 22 11:25:40 2008 From: EsbenS at TCElectronic.com (Esben Skovenborg) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Double trouble In-Reply-To: <20080120085717.GA18917@karelia> References: <20061207152421.GA23270@karelia> <20080116090104.GB26706@karelia> <20080120085717.GA18917@karelia> Message-ID: Hi Boris, Your custom-double example was very helpful, and the beta-2 version thus seems to solve the problems that we've discussed. The new Inf/NaN support for xsd:double also works well. Cheers, Esben -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Sunday, January 20, 2008 9:57 AM To: Esben Skovenborg Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Double trouble Hi Esben, Esben Skovenborg writes: > I think it would be most natural to map xsd:double to C++ double, as > in your "even better solution", below. What would I need to do? Ok, I've added the necessary support to the compiler. The pre-release binary is here (I assumed you are using Windows): http://www.codesynthesis.com/~boris/tmp/xsd-3.1.0.b2-i686-windows.zip I've also create an example that shows how to re-map xsd:double and xsd:decimal: http://www.codesynthesis.com/~boris/tmp/custom-double.zip It implements serialization of xsd:double in scientific notation. There is the README file that explains what's going on. When adopting to your application, you would replace test.xsd with your own schema and change the code in *-parsing.hxx and *-serialization.hxx if necessary (e.g., you may want to set your own precisions, etc.). > A related issue is the handling of +/-INF and NaN 'special values' of > xsd:double elements (http://www.w3.org/TR/xmlschema-2/#double). Will > these values be supported by the XSD 3.1 serializer? and by the parser? Yes, they are supported by the pre-release and the custom-double example. Boris From jnw at xs4all.nl Tue Jan 22 12:19:49 2008 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] cxx-tree: Problems with keep_dom and throwing custom type constructors Message-ID: <21706.194.109.230.85.1201022389.squirrel@webmail.xs4all.nl> Hi Boris, [This thread started as "Re: [xsd-users] cxx-parser: Not all attributes in the XML namespace are typemapped." The previous message in this thread is http://codesynthesis.com/pipermail/xsd-users/2008-January/001444.html ] Boris Kolpackov wrote: > Jeroen N. Witmond [Bahco] writes: >> I've fixed this bug by making the following change in the generated >> code: [snip] > The problem with this fix is that it will result in a memory leak > if an exception is thrown from metadox::foo before the constructor > for the root type is called. This will happen, for example, if the > root element in the document does not match that expected by the > parsing function. Yep, my unittest did not include that scenario. It does now, and as expected it shows the leak. And I shouldn't have called it a fix, because it is just an incomplete hack in generated code. But it did allow me to verify that the problem is not in my code. :) > In normal circumstances this kind of problem is address by passing > an automatic pointer (e.g., dom::auto_ptr) which is reset at the > point where the new object assumes ownership of the resource. By normal circumstances I assume you mean you do not want to change the API. > In > our case, we pass a root element to the constructor and depending > on the flag (keep_dom), the constructor also assumes ownership of > the document. An ugly, but workable solution would be to pass a > pointer to the dom::auto_ptr as user data attached to the document. > This way the root type constructor can reset auto_ptr when it assumes > ownership. Let me know if you have a better idea ;-). You're right, it's ugly, it's workable, and, if my assumption above is correct, I don't have any better ideas. :) Jeroen. From olitour at gmail.com Tue Jan 22 19:20:09 2008 From: olitour at gmail.com (Olivier Tournaire) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Help on parsing GML In-Reply-To: <20080122071216.GA5692@karelia> References: <479539DD.5090601@gmail.com> <20080122071216.GA5692@karelia> Message-ID: <47968839.1060703@gmail.com> Thank you Boris for your answer. Finally, I choose to parse a CityGML file instead of a GML one. I generate the C++ code from the CityGML 0.4.0 schema with this command line : xsd cxx-tree --generate-polymorphic --generate-doxygen --namespace-map http://www.citygml.org/citygml/1/0/0=CityGML --namespace-map urn:oasis:names:tc:ciq:xsdschema:xAL:2.0=urn_oasis_names_tc_ciq_xsdschema_xAL_2_0 CityGML.xsd Then, thanks to your tips, I wrote this small piece of code : #include #include #include #include #include "CityGML.hxx" int main(int argc , char** argv ) { std::string filename("C:\\Documents and Settings\\Olivier\\Bureau\\FZK-House_LOD1\\FZK_Haus_LOD1.gml"); std::ofstream log("log.txt"); try { log << "Parsing file " << filename << std::endl; std::auto_ptr r ( CityGML::CityModel(filename) ); log << "File parsed with success !" << std::endl; CityGML::CityModelType::_GenericApplicationPropertyOfCityModel_iterator iterator_begin, iterator_end; CityGML::CityModelType::_GenericApplicationPropertyOfCityModel_sequence seqCity = r->_GenericApplicationPropertyOfCityModel(); iterator_begin = seqCity.begin(); iterator_end = seqCity.end(); } catch (const xml_schema::exception& e) { log << "Error parsing file !" << std::endl; log << e << std::endl; log.close(); return EXIT_FAILURE; } log.close(); return EXIT_SUCCESS; } Here are the first lines of the CityGML file : AC90-FZK-Haus-2x3-63020_ 3458643.83172578 5440407.10899672 -1 3458665.08225378 5440425.41250692 6.3176914694611 ... ... ... I use VC 2003, so, I turn RTTI. Then, everything compiles fine, with only 4 warnings related to the maximum number of lines the compiler can support (CityGML.hxx and CityGML.cxx are very very very long). Then, I run the program, and everything went well. No, I would like to know how can I access for example the tag AC90-FZK-Haus-2x3-63020_ ? I am able to obtain a const iterator to a sequence of _GenericApplicationPropertyOfCityModel. Then, back to CityGML schema, I found these line : So, dereferencing iterator_begin, I obtain a xml_schema::type which is a typedef for ::xsd::cxx::tree::type. However, I do not know what to do with that stuff ... Here is an other line I found in the CityGML schema : I tried this, but it does not compile : for (;iterator_begin!=iterator_end;iterator_begin++) { if ( dynamic_cast( (*iterator_begin).pointer ) == true ) ; // ... } error C2039: 'pointer' : n'est pas membre de 'xsd::cxx::tree::_type' Please could you help me ? Best regards Olivier Tournaire Boris Kolpackov a ?crit : > Hi Olivier, > > Olivier Tournaire writes: > > >> First, as I am not familiar with GML, I would like to have a small >> sample with, for example, only points. Could you help me ? >> > > A better place to look for GML document samples would be on the GML > publisher's website: > > http://www.opengeospatial.org/ > > They also have a forum dedicated to GML where you can ask GML-related > questions. > > > >> Then, xsd cxx-tree generated a lot of C++ classes, and I do not know >> where to begin. What object do I have to declare in order to parse a GML >> file? >> > > First, I strongly recommend that you read through the C++/Tree Mapping > Getting Started Guide: > > http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/ > > This should give you an idea on how to parser and access GML documents. > Generally, you would first identify the document's root element by > looking at your sample documents (let's say it is called 'root'). Then > you would look for a declaration of this element in the schema and > determine its type (let's say it is 'type'). Based on this information > you can then write: > > auto_ptr r = root ("sample.xml"); > > Boris > > -- Le temps des cerises reviendra. Dans l'imm?diat, c'est le temps des noyaux. Courage. From boris at codesynthesis.com Wed Jan 23 02:40:07 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] Help on parsing GML In-Reply-To: <47968839.1060703@gmail.com> References: <479539DD.5090601@gmail.com> <20080122071216.GA5692@karelia> <47968839.1060703@gmail.com> Message-ID: <20080123074007.GA28584@karelia> Hi Olivier, Olivier Tournaire writes: > No, I would like to know how can I access for example the tag > AC90-FZK-Haus-2x3-63020_ ? I am able to obtain a > const iterator to a sequence of _GenericApplicationPropertyOfCityModel. > Then, back to CityGML schema, I found these line : > > type="xs:anyType" abstract="true"/> > > So, dereferencing iterator_begin, I obtain a xml_schema::type which is a > typedef for ::xsd::cxx::tree::type. However, I do not know what to do > with that stuff ... CityGML (and GML) use polymorphism. For more information on support for polymorphism in the C++/Tree mapping see Section 2.11, "Mapping for xsi:type and Substitution Groups" in the C++/Tree Mapping User Manual: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.11 xs:anyType is mapped to xml_schema::type. Once you get a reference to it, you can try to dynamic_cast it to various types (e.g., types for gml:name and gml:boundedBy elements) as shown in the sample code for Section 2.11. > substitutionGroup="gml:featureMember"/> > > I tried this, but it does not compile : > > for (;iterator_begin!=iterator_end;iterator_begin++) > { > if ( dynamic_cast( > (*iterator_begin).pointer ) == true ) > ; // ... This is covered in the above-mentioned section. The last line should look like this instead: if (FeaturePropertyType* fpt = dynamic_cast (&(*iterator_begin))); { // It is a FeaturePropertyType, use fpt. } else { // Something else. } Boris From mcapogreco at hotmail.com Tue Jan 22 21:01:01 2008 From: mcapogreco at hotmail.com (Mark Capogreco) Date: Sun Oct 11 15:34:00 2009 Subject: [xsd-users] terminate called after throwing an instance of 'xsd::cxx::xml::invalid_utf8_string' Message-ID: Hi, I received the above error running an C++ openMPI parallel application, which is an extension to my previously normal C++ app. Which worked well with XSD. The following is a description of what has occurred. - I run my C++ app. Fine utilising XSD with no error. - I added openMPI code and still run well under normal C++ environement. - I tried then running the C++ app on the Parallel Tools Platform in eclipse 3.2 using only one node and received the above error. The same error occurs for several nodes. I was hoping someone could give me some detail on the error so I can see why I can't input my parameters using XSD in the parallel environment. Any assistance greatly appreciated. Thanks Mark From david.r.moss at selex-comms.com Wed Jan 23 03:46:03 2008 From: david.r.moss at selex-comms.com (david.r.moss@selex-comms.com) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Re: In-memory validation In-Reply-To: <20080121073956.GB29391@karelia> Message-ID: Boris, Thanks for that, it re-enforces some of the issues we've thought of here! I need to give it some thought - I will get back to you! Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@selex-comms.com Boris Kolpackov Sent by: xsd-users-bounces@codesynthesis.com 01/21/08 07:39 AM To david.r.moss@selex-comms.com cc xsd-users@codesynthesis.com Subject [xsd-users] Re: In-memory validation Hi David, After some more thinking and experimentation on the subject of in- memory validation I would like to get your thoughts on our current view of how it can be implemented and whether it will still be useful for you project. You initial use-case (quoted below) calls for what I would call "immediate detection" of validation errors. Based on this notion of immediate detection, we can place every XML Schema validation construct (e.g., maxOccurs/minOccurs, ordering of elements, facets, uniqueness, etc.) into one of the three categories: 1. Desirable and possible/efficient to implement 2. Desirable and impossible/inefficient to implement 3. Undesirable Into the "desirable and possible/efficient" category fall, for example, the enforcement of xsd:ID uniqueness constraint as well as maxOccurs and the maxLength list facet. The "desirable and impossible/inefficient" category contains the bulk of the XML Schema validation constructs. These include most of the facets and key/keyref/unique constructs. Let's consider the minInclusive and maxInclusive facets from your example below. The range checking code will have to be called after every modification to the underlying int value. In the current architecture you can do, for example, the following: int& i = rt->bounded_int(); // Get a reference to the "base" type (int) i = 100; // Impossible to detect. This is an example of a check that is impossible to implement in the current C++/Tree architecture. A check that is possible but inefficient to implement is, for example, the pattern facet on xsd:string. The pattern checking code (most likely a virtual function with quite an expensive body) will have to be called every time a modification is made to any single character in the underlying string. Then there is a number of undesirable checks that, if enforced immediately, would make the object model very awkward to use. These are minOccurs, the length and minLength list facets, ordering of elements, as well as compound keys in key/unique. The problem with all these constraints is that you may need to perform several operations (e.g., several push_back's for minOccurs and element ordering or modification of several elements/attributes for compound key/unique) before the resulting object model becomes valid. Based on these considerations, it appears that while the "immediate detection" model may look appealing on the surface, in reality it is either not practical or undesirable for the majority of XML Schema constructs. This brings us to the next option: "on-demand detection". The idea is that each generated class will have the validate() function which can be called to detect validation errors on a fragment of object model: rt->bounded_int( 50 ); rt->restricted_string( "abc" ); rt->validate (); // Exception is thrown if invalid. There is, however, a number of questions about practical usefulness and implementation of this model: 1. How to point to the error location? Possible options: (1) a reference to the invalid node passed as xml_schema::type& (drawback: hard to know the actual type and thus to do anything about the error), (2) XPath identifying the error location (drawback: impossible to use to correct the error). 2. Some errors may be impossible for the application to correct. For example, if an error indicates that a string does not match a pattern, what is the application going to do? 3. If error correction by the application is hard/impossible then what is the use of in-memory validation other then to know whether the object model is valid/invalid? I would therefore appreciate any feedback on these concerns as well as on what people expect from the in-memory validation facility in their applications. Thanks, Boris david.r.moss@selex-comms.com writes: > A while ago there was talk of in-memory validation as outlined in an > example below. > > Example code: > > // Load will fail when content is invalid. > auto_ptr rt( root( "in-memory-validation-test.xml" ) ); > > // Modify with a valid value (range is 20-80 inclusive). > rt->bounded_int( 50 ); > cout << *rt << endl; > > rt->bounded_int( 100 ); // Ideally, this should fail (throw exception - as > initial file load would) > cout << *rt << endl; > > > I believe this kind of capability was on your 'to do' list at one point; > is this still the case and, if so, do you have an idea of time-scales?! > > Cheers, > Dave. ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel. SELEX Communications Limited is a Private Limited Company registered in England and Wales under Company Number 964533 and whose Registered Office is Marconi House, New Street, CHELMSFORD, Essex. CM1 1PL. England. From boris at codesynthesis.com Wed Jan 23 04:35:25 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] terminate called after throwing an instance of 'xsd::cxx::xml::invalid_utf8_string' In-Reply-To: <002901c85d63$cd76a770$6863f650$@com> References: <002901c85d63$cd76a770$6863f650$@com> Message-ID: <20080123093525.GA3344@karelia> Hi Mark, Mark Capogreco writes: > I received the above error running an C++ openMPI parallel application, > which is an extension to my previously normal C++ app. Which worked well > with XSD. The following is a description of what has occurred. > > - I run my C++ app. Fine utilising XSD with no error. > > - I added openMPI code and still run well under normal C++ > environement. > > - I tried then running the C++ app on the Parallel Tools Platform > in eclipse 3.2 using only one node and received the above error. The same > error occurs for several nodes. > > I was hoping someone could give me some detail on the error so I can see why > I can't input my parameters using XSD in the parallel environment. The invalid_utf8_string exception is thrown by the text conversion function when an invalid UTF8 character or character sequence is encountered. One thing to note is that this should only happen when you try to serialize the object model to XML (that's when UTF-8 to UTF-16 conversion is happening). So if all you are doing is parsing XML to object model then the fact that you are getting this exception is very strange. If you do serialize to XML then the most likely reason for this exception is that a string in the object model contains invalid UTF-8 text. Seeing that you are running in a parallel environment, perhaps there is a race condition which gobbles up the data. One way to try and track down the problem would be to get a stack trace (e.g., by getting a core and examining it with gdb). This way you can actually examine the string being converted which should give you a better idea about what's going on. Boris From boris at codesynthesis.com Wed Jan 23 07:58:29 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Re: cxx-tree: Problems with keep_dom and throwing custom type constructors In-Reply-To: <21706.194.109.230.85.1201022389.squirrel@webmail.xs4all.nl> References: <21706.194.109.230.85.1201022389.squirrel@webmail.xs4all.nl> Message-ID: <20080123125829.GC3344@karelia> Hi Jeroen, Jeroen N. Witmond [Bahco] writes: > By normal circumstances I assume you mean you do not want to > change the API. Right. > You're right, it's ugly, it's workable, and, if my assumption above is > correct, I don't have any better ideas. :) Ok, I've implemented the fix and it will appear in the upcoming 3.1.0. Boris From malig at sempratrading.com Wed Jan 23 13:14:28 2008 From: malig at sempratrading.com (Alig, Michael) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Using xsd inheritance Message-ID: <0819B43367D93E4FB638B231A03EDA9606B9DEB9@STMAIL6.SEMPRATRADING.COM> Boris, I am very impressed with XSD! I have successfully used it in my current project. The xsd has now changed to use inheritance Ex. except I am having problems parsing the subclasses, only the base parser impl is called. I tried to follow the example referenced on the Wiki 'Various ways to handle pervasive content using the xml:base attribute as an example, by Jeroen N. Witmond " but I have had no luck (so far). Any suggestions and/or examples? Any help would be greatly appreciated. Thanks, Michael Michael Alig Sempra Energy Trading Work : 203-355-5719 Mobile : 845-729-0760 **************************************************************************** This e-mail contains privileged attorney-client communications and/or confidential information, and is only for the use by the intended recipient. Receipt by an unintended recipient does not constitute a waiver of any applicable privilege. Reading, disclosure, discussion, dissemination, distribution or copying of this information by anyone other than the intended recipient or his or her employees or agents is strictly prohibited. If you have received this communication in error, please immediately notify us and delete the original material from your computer. Sempra Energy Trading LLC (SET) is not the same company as SDG&E or SoCalGas, the utilities owned by SET's parent company. SET is not regulated by the California Public Utilities Commission and you do not have to buy SET's products and services to continue to receive quality regulated service from the utilities. Sempra Energy Europe disclosure: Sempra Energy Europe Limited registered in England & Wales No. 3704235 registered office 111 Old Broad Street London EC2N 1SE United Kingdom. Sempra Energy Trading (UK) Limited registered in England & Wales No. 3526627 registered office 111 Old Broad Street London EC2N 1SE United Kingdom FSA firm reference number 188751. Sempra Energy Trading Holdings Limited registered in England & Wales No. 3704239 registered office 111 Old Broad Street London EC2N 1SE United Kingdom. *************************************************************************** From jnw at xs4all.nl Wed Jan 23 14:26:23 2008 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Using xsd inheritance Message-ID: <22443.194.109.230.85.1201116383.squirrel@webmail.xs4all.nl> Alig, Michael wrote: > I am having problems parsing the subclasses, only the base parser impl > is called. I tried to follow the > > example referenced on the Wiki > > 'Various ways to handle pervasive content using the xml:base > attribute as an example, by Jeroen N. Witmond > " > > but I have had no luck (so far). Perhaps there is some confusion about the meaning of inheritance. In my work on the attributes in the xml namespace, I'm handling the inheritance of the values of the attributes in the xml file being parsed. As I understand it, you are using Schema type inheritance, which is different thing. HTH. Jeroen. From boris at codesynthesis.com Wed Jan 23 14:29:09 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Using xsd inheritance In-Reply-To: <0819B43367D93E4FB638B231A03EDA9606B9DEB9@STMAIL6.SEMPRATRADING.COM> References: <0819B43367D93E4FB638B231A03EDA9606B9DEB9@STMAIL6.SEMPRATRADING.COM> Message-ID: <20080123192909.GA7588@karelia> Hi Michael, Alig, Michael writes: > I am very impressed with XSD! I have successfully used it in my current > project. Great, I am glad you enjoy it! > The xsd has now changed to use inheritance > > > > >From the presence of the abstract="true" attribute, I gather you are using XML Schema polymorphism in the form of xsi:type or substitution groups. The C++/Parser mapping currently does not support XML Schema polymorphism though we are planning to add this support soon. Can you confirm that you are using either xsi:type or substitution groups (or both)? Thanks, Boris From a.colombo at kingston.ac.uk Fri Jan 25 05:29:08 2008 From: a.colombo at kingston.ac.uk (Alberto Colombo) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] terminate called after throwing an instance of 'xsd::cxx::xml::invalid_utf8_string' In-Reply-To: <20080123093525.GA3344@karelia> References: <002901c85d63$cd76a770$6863f650$@com> <20080123093525.GA3344@karelia> Message-ID: <1201256948.32759.34.camel@caretaker1> Hello, I have the same problem, with this unusual exception being thrown when I try to *parse* a document. I have a class defined like this: class KanannotateHelper { public: KanannotateHelper(std::string layout_filename) throw (xml_schema::exception); KanannotateHelper (std::string, std::auto_ptr); // ... }; where ka::TopologyType is generated by XSD. In my main, I can do like this: std::auto_ptr topology; topology = ka::topology(layout_file); KanannotateHelper kh(layout_file, topology); And it works fine, using the second constructor. On the other hand, if I try to use the first constructor: KanannotateHelper kh(layout_file); which is defined as KanannotateHelper::KanannotateHelper (string _layout_filename) throw (xml_schema::exception) : layout_filename( _layout_filename ), topology( ka::topology( layout_filename ) ) {} I get the exception thrown. This happens on a normal SuSE system, no MPI involved (it's a dual core, indeed, but does that matter?). I did not dwell on the problem since I found an easy workaround, but I thought it may be of interest to others... Many thanks to Boris and the XSD team for their time and their software. Best Regards Alberto On Wed, 2008-01-23 at 11:35 +0200, Boris Kolpackov wrote: > Hi Mark, > > Mark Capogreco writes: > > > I received the above error running an C++ openMPI parallel application, > > which is an extension to my previously normal C++ app. Which worked well > > with XSD. The following is a description of what has occurred. > > > > - I run my C++ app. Fine utilising XSD with no error. > > > > - I added openMPI code and still run well under normal C++ > > environement. > > > > - I tried then running the C++ app on the Parallel Tools Platform > > in eclipse 3.2 using only one node and received the above error. The same > > error occurs for several nodes. > > > > I was hoping someone could give me some detail on the error so I can see why > > I can't input my parameters using XSD in the parallel environment. > > The invalid_utf8_string exception is thrown by the text conversion > function when an invalid UTF8 character or character sequence is > encountered. One thing to note is that this should only happen when > you try to serialize the object model to XML (that's when UTF-8 to > UTF-16 conversion is happening). So if all you are doing is parsing > XML to object model then the fact that you are getting this exception > is very strange. > > If you do serialize to XML then the most likely reason for this > exception is that a string in the object model contains invalid > UTF-8 text. Seeing that you are running in a parallel environment, > perhaps there is a race condition which gobbles up the data. > > One way to try and track down the problem would be to get a stack > trace (e.g., by getting a core and examining it with gdb). This > way you can actually examine the string being converted which > should give you a better idea about what's going on. > > Boris > > > This email has been scanned for all viruses by the MessageLabs Email > Security System. -- Alberto Colombo, MSc PhD student at Digital Imaging Research Centre Kingston University, London e-mail: a.colombo@kingston.ac.uk cell: +44 77267 11980 http://dircweb.king.ac.uk/Ris/queries/pages/home_page.asp?AuthorID=925 This email has been scanned for all viruses by the MessageLabs Email Security System. From boris at codesynthesis.com Fri Jan 25 08:14:13 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] terminate called after throwing an instance of 'xsd::cxx::xml::invalid_utf8_string' In-Reply-To: <1201256948.32759.34.camel@caretaker1> References: <002901c85d63$cd76a770$6863f650$@com> <20080123093525.GA3344@karelia> <1201256948.32759.34.camel@caretaker1> Message-ID: <20080125131413.GB5391@karelia> Hi Alberto, Alberto Colombo writes: > I have the same problem, with this unusual exception being thrown when > I try to *parse* a document. I have a class defined like this: > > [...] > > And it works fine, using the second constructor. On the other hand, if I > try to use the first constructor: > > KanannotateHelper kh(layout_file); > > which is defined as > > KanannotateHelper::KanannotateHelper (string _layout_filename) throw > (xml_schema::exception) : layout_filename( _layout_filename ), > topology( ka::topology( layout_filename ) ) > {} > > I get the exception thrown. Hm, interesting. There is only one place where the UTF-8 to UTF-16 conversion code is called in case of parsing a file identified by name or a URI and that is the code that converts the file name/URI to UTF-16. So the only reason why this exception would be thrown is if the file name string was invalid. In your case what immediately comes to mind is the possibility that the layout_filename and topology member variables are initialized in the wrong order. In this case you would be using layout_filename which hasn't been constructed yet and would therefore contain garbage which, in turn, would most likely trigger the exception. Can you confirm that layout_filename is declared before topology in KanannotateHelper class? Boris From a.colombo at kingston.ac.uk Fri Jan 25 09:25:28 2008 From: a.colombo at kingston.ac.uk (Alberto Colombo) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] terminate called after throwing an instance of 'xsd::cxx::xml::invalid_utf8_string' In-Reply-To: <20080125131413.GB5391@karelia> References: <002901c85d63$cd76a770$6863f650$@com> <20080123093525.GA3344@karelia> <1201256948.32759.34.camel@caretaker1> <20080125131413.GB5391@karelia> Message-ID: <1201271128.32759.47.camel@caretaker1> Hello Boris, > > KanannotateHelper::KanannotateHelper (string _layout_filename) throw > > (xml_schema::exception) : layout_filename( _layout_filename ), > > topology( ka::topology( layout_filename ) ) > > {} > > > > I get the exception thrown. > In your case what immediately comes to mind is the possibility that > the layout_filename and topology member variables are initialized > in the wrong order. In this case you would be using layout_filename > which hasn't been constructed yet and would therefore contain > garbage which, in turn, would most likely trigger the exception. > Can you confirm that layout_filename is declared before topology > in KanannotateHelper class? layout_filename is declared *after* topology, your guess was correct... Thanks a lot for your help! Regards Alberto > > > Boris > > This email has been scanned for all viruses by the MessageLabs Email > Security System. -- Alberto Colombo, MSc PhD student at Digital Imaging Research Centre Kingston University, London e-mail: a.colombo@kingston.ac.uk cell: +44 77267 11980 http://dircweb.king.ac.uk/Ris/queries/pages/home_page.asp?AuthorID=925 This email has been scanned for all viruses by the MessageLabs Email Security System. From jeffery at envisagereality.com Sun Jan 27 22:54:04 2008 From: jeffery at envisagereality.com (jeffery@envisagereality.com) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] (no subject) Message-ID: <20080127195404.q9teo5n0o40s80w0@envisagereality.com> Hi, my current project involve in loading huge xml files. Is there any support for serialisation to binary, or something similar to reduce the loading time of the files? Thanks. Jeffrey. From boris at codesynthesis.com Mon Jan 28 01:24:09 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Binary serialization In-Reply-To: <20080127195404.q9teo5n0o40s80w0@envisagereality.com> References: <20080127195404.q9teo5n0o40s80w0@envisagereality.com> Message-ID: <20080128062409.GA19525@karelia> Hi Jeffrey, jeffery@envisagereality.com writes: > my current project involve in loading huge xml files. Is there any > support for serialisation to binary, or something similar to reduce > the loading time of the files? Yes, the C++/Tree mapping supports binary serialization (CDR and XDR are supported out of the box, custom formats can be easily added). You are also correct in assuming that the parsing time will be much better (we have observed an order of magnitude improvement). The 'binary' example, which can be found in the examples/cxx/tree/ directory of XSD distribution shows how to save the object model to and load it from ACE CDR streams. The next version of XSD (due in a week or two) adds examples for XDR and a custom format (using Boost serialization library as an example). These examples should also work with 3.0.0 so I can send them to you if you would like. Boris From sbalasub at qualcomm.com Mon Jan 28 02:08:20 2008 From: sbalasub at qualcomm.com (Balasubramanyam, Shivakumar) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Binary serialization In-Reply-To: <20080128062409.GA19525@karelia> References: <20080127195404.q9teo5n0o40s80w0@envisagereality.com> <20080128062409.GA19525@karelia> Message-ID: Boris, I would be interested in the Boost serialization examples. Thanks, Shiva -----Original Message----- From: xsd-users-bounces@codesynthesis.com [mailto:xsd-users-bounces@codesynthesis.com] On Behalf Of Boris Kolpackov Sent: Sunday, January 27, 2008 10:24 PM To: jeffery@envisagereality.com Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Binary serialization Hi Jeffrey, jeffery@envisagereality.com writes: > my current project involve in loading huge xml files. Is there any > support for serialisation to binary, or something similar to reduce > the loading time of the files? Yes, the C++/Tree mapping supports binary serialization (CDR and XDR are supported out of the box, custom formats can be easily added). You are also correct in assuming that the parsing time will be much better (we have observed an order of magnitude improvement). The 'binary' example, which can be found in the examples/cxx/tree/ directory of XSD distribution shows how to save the object model to and load it from ACE CDR streams. The next version of XSD (due in a week or two) adds examples for XDR and a custom format (using Boost serialization library as an example). These examples should also work with 3.0.0 so I can send them to you if you would like. Boris From sbalasub at qualcomm.com Mon Jan 28 02:12:10 2008 From: sbalasub at qualcomm.com (Balasubramanyam, Shivakumar) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Seperation of Data and serialization code Message-ID: Boris, I am sure this question is repeated, sorry about that. Is there anyway today that I can separate the code generation of the Data (representing the XSD schema) and the serialization code? This would mostly help the layering of the software where the software modules would just depend on the data and does not know how it is actually being serialized in the system. For example, we may move from XML to XDR or to Custom serialization library, but that would not require re-building the application software. In simple, it would facilitate a loosely coupled software design. Thanks, Shiva From boris at codesynthesis.com Mon Jan 28 14:19:04 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] Seperation of Data and serialization code In-Reply-To: References: Message-ID: <20080128191904.GD22822@karelia> Hi Shiva, Balasubramanyam, Shivakumar writes: > Is there anyway today that I can separate the code generation of the > Data (representing the XSD schema) and the serialization code? > > This would mostly help the layering of the software where the software > modules would just depend on the data and does not know how it is > actually being serialized in the system. For example, we may move from > XML to XDR or to Custom serialization library, but that would not > require re-building the application software. There is no way to do this at the moment. By serialization I assume you mean both XML (or binary) parsing and serialization. If that's the case, then there is one problem with supporting something like this in the future. While it is possible to separate serialization from the object model because it is implemented as operators and global functions, this approach won't work for parsing because it is implemented as constructors and global functions. We choose to use constructors for parsing in order to make the interface help prevent construction of invalid object models by not providing default constructors for types with required elements or attributes. If we used something other than constructors for parsing the we would have had to provide default constructors for all type since parsing would have been performed in two steps: construction first and then parsing. Boris From uri at hyperroll.com Tue Jan 29 03:33:52 2008 From: uri at hyperroll.com (Uri Karagila) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] std::size_t and auto_ptr::reset() are not defined for MS C++ compiler for Itanium from MS DDK In-Reply-To: <479EE259.4050907@hyperroll.com> References: <479EE259.4050907@hyperroll.com> Message-ID: <783879783B65E44995520FEF376C45383985ED@ilexch1.int.hyperroll.com> Hi, please review and advise. C:\>xsd version CodeSynthesis XSD XML Schema to C++ compiler 3.0.0 Copyright (C) 2005-2007 Code Synthesis Tools CC C:\>cl /? Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.39 for IA-64 Copyright (C) Microsoft Corporation. All rights reserved. ... c:\buildtools\Windows\xsd\libxsd\xsd\cxx\tree\elements.hxx(280) : error C2039: 'reset' : is not a member of 'std::auto_ptr<_Ty>' with [ _Ty=xsd::cxx::tree::_type::map ] c:\buildtools\Windows\xsd\libxsd\xsd\cxx\tree\elements.hxx(854) : error C2039: 'size_t' : is not a member of 'std' c:\buildtools\Windows\xsd\libxsd\xsd\cxx\tree\elements.hxx(873) : see reference to class template instantiation 'xsd::cxx::tree::enum_comparator' being compiled c:\buildtools\Windows\xsd\libxsd\xsd\cxx\tree\elements.hxx(860) : error C2039: 'size_t' : is not a member of 'std' c:\buildtools\Windows\xsd\libxsd\xsd\cxx\tree\elements.hxx(866) : error C2039: 'size_t' : is not a member of 'std' c:\buildtools\Windows\xsd\libxsd\xsd\cxx\tree\elements.hxx(866) : error C2039: 'size_t' : is not a member of 'std' Regards Uri From boris at codesynthesis.com Tue Jan 29 03:52:15 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:01 2009 Subject: [xsd-users] std::size_t and auto_ptr::reset() are not defined for MS C++ compiler for Itanium from MS DDK In-Reply-To: <783879783B65E44995520FEF376C45383985ED@ilexch1.int.hyperroll.com> References: <479EE259.4050907@hyperroll.com> <783879783B65E44995520FEF376C45383985ED@ilexch1.int.hyperroll.com> Message-ID: <20080129085215.GB24761@karelia> Hi Uri, Uri Karagila writes: > Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.39 for IA-64 > ... This is the same major version as in Visual Studio 2005 (8.0). > > c:\buildtools\Windows\xsd\libxsd\xsd\cxx\tree\elements.hxx(280) : error > C2039: 'reset' : is not a member of 'std::auto_ptr<_Ty>' > with > [ > _Ty=xsd::cxx::tree::_type::map > ] > c:\buildtools\Windows\xsd\libxsd\xsd\cxx\tree\elements.hxx(854) : error > C2039: 'size_t' : is not a member of 'std' Hm, looks like Microsoft forgot to update their standard C++ headers for IA-64 and/or DDK. Here are the possible solutions that come to mind: 1. Upgrade to a newer version of DDK or use Visual Studio 2005 to build your code. An SP1 was released recently for VS 2005. Perhaps there is also an updated version or SP1 for DDK available. If none of this works, it is a good idea to report this to Microsoft. 2. Replace the 'memory' and 'cstddef' headers in DDK with the versions from VS 2005 (can be found in the VC/include/ directory). 3. Change the libxsd code to use assignment instead of reset and size_t instead of std::size_t. If you don't used binary serialization then the generated code shouldn't use any of these constructs. However, this should be considered as only a temporary solution since we won't be making these changes in the future releases. Boris