From yianisn at gmail.com Fri Mar 2 05:05:48 2007 From: yianisn at gmail.com (Yianis Nikolaou) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML encoding Message-ID: hello all, I would like to stream a XML tree to a file with encoding iso-8859-7 I currently use the following procedure ...... std::ofstream ofs ("result.xml"); xml_schema::namespace_infomap map; project (ofs, p, map); where p is an instance of my project. The generated file using Unicode encoding (UTF-8). Is there a way to change that? thanks yianis From boris at codesynthesis.com Fri Mar 2 05:38:55 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML encoding In-Reply-To: References: Message-ID: <20070302103855.GA6699@karelia> Hi Yianis, Yianis Nikolaou writes: > I would like to stream a XML tree to a file with encoding iso-8859-7 > > I currently use the following procedure > > ...... > std::ofstream ofs ("result.xml"); > xml_schema::namespace_infomap map; > project (ofs, p, map); > > The generated file using Unicode encoding (UTF-8). Is there a way to > change that? Yes, by passing "ISO8859-7" to the serialization function: project (ofs, p, map, "ISO8859-7"); This is documented in the Section 4.2, "Namespace Infomap and Character Encoding" of the C++/Tree Mapping Manual: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#4.2 Also note that depending on how you've built Xerces-C++ this encoding may not be supported. But I am pretty sure you will get it if you build Xerces-C++ with ICU. hth, -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/20070302/261e3ac6/attachment.pgp From yianisn at gmail.com Fri Mar 2 08:26:43 2007 From: yianisn at gmail.com (Yianis Nikolaou) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML encoding In-Reply-To: <20070302103855.GA6699@karelia> References: <20070302103855.GA6699@karelia> Message-ID: thank you very much for your prompt reply! I guess the standard Xerces library that I downloaded along with XSD does not suport iso-8859-7 since I get an empty file when I call project (ofs, p, map, "ISO8859-7"); The problem I am trying to solve has to do with Greek character (hence the iso-8859-7). When I run xsd with the default char size I get an exception invalid_utf8_string from string.ixx when I use Greek characters in string fields. When I use wchar_t it works fine, but the output is UNICODE and not viewable by notepad etc. Questions: Q1: If Xerces recognized the iso8859-7 and I used wchars, then would I get the correct output in iso8859-7 and not Unicode? Q2: If I compile XSD with XSD_USE_LCP defined, would I be able to enter Greek characters in standard char mode without getting the exception invalid_utf8_string? thank you in advance! yianis PS Greek Characters, just in case you would like to test something (-: abcdezh iklmn oprstu xy ???????????????????????? On 3/2/07, Boris Kolpackov wrote: > > Hi Yianis, > > Yianis Nikolaou writes: > > > I would like to stream a XML tree to a file with encoding iso-8859-7 > > > > I currently use the following procedure > > > > ...... > > std::ofstream ofs ("result.xml"); > > xml_schema::namespace_infomap map; > > project (ofs, p, map); > > > > The generated file using Unicode encoding (UTF-8). Is there a way to > > change that? > > Yes, by passing "ISO8859-7" to the serialization function: > > project (ofs, p, map, "ISO8859-7"); > > > This is documented in the Section 4.2, "Namespace Infomap and Character > Encoding" of the C++/Tree Mapping Manual: > > http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#4.2 > > > Also note that depending on how you've built Xerces-C++ this encoding > may not be supported. But I am pretty sure you will get it if you > build Xerces-C++ with ICU. > > > hth, > -boris > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iQGVAwUBRef+v8iAKQuuCE8dAQKhIAv/XT8Ulxe6RxZSFqip6MqI9nbfb5sQFE1X > oPmaaJd+IpJzO8FnOL4s3zquIOhzkIZHB6vtUx8BOzODfyv+sXetqvnggq6KcDcm > ruzNEFKbnUWLyzbWKlEFcOyXDilwV1VTVKVR0Yh5sF6i+QSeqAhDkOJsdY8G+512 > g4DnqDduU8Pr+B26ajSdRyt/fQqX3wAmpXvV1LmTnGt0xZq3hp9OlpNytGjk2Dku > JokTu+JI3P8Bb+HHCM/hRI2nPWcgq4rLWFmLatvTmode+ECFKUPWZr3aDhWDWhxm > Hb/AU9lZdzUAS+yVQjr+M6MxAJDiz4CoSf65as19HlQQ/cljCy/QmhLa5sw5j+yQ > KJ6GgTzdsyVCCJF4SGkkCmhQmKf5yP/hMbC+T9t+ZDYE8FXK90G40H59E1drym98 > Z+rlRFHyoEpdjntrQkGdC4/dz7Av1Us9p8nKWLzI1lQDrg+GtEBUIhE9Ho88njYD > OhwWG9BGW/6Gu4P24mV54DbCbPc2lfNO > =Uji7 > -----END PGP SIGNATURE----- > > From boris at codesynthesis.com Fri Mar 2 08:47:20 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML encoding In-Reply-To: References: <20070302103855.GA6699@karelia> Message-ID: <20070302134720.GA10970@karelia> Hi Yianis, Yianis Nikolaou writes: > I guess the standard Xerces library that I downloaded along with XSD does > not suport iso-8859-7 since I get an empty file when I call > > project (ofs, p, map, "ISO8859-7"); Not an exception? > When I run xsd with the default char size I get an exception > invalid_utf8_string from string.ixx when I use Greek characters in string > fields. Right, since char is expected to contain UTF-8. > Questions: > Q1: If Xerces recognized the iso8859-7 and I used wchars, then would I get > the correct output in iso8859-7 and not Unicode? Yes you should be able to. > Q2: If I compile XSD with XSD_USE_LCP defined, would I be able to enter > Greek characters in standard char mode without getting the exception > invalid_utf8_string? Yes, if you compiled the generated code with XSD_USE_LCP and your system code page is iso8859-7 (or equivalent Windows name) then you should be able to pass Greek characters in char. You may also be able to save it as iso8859-7 (or Windows name) using Xerces-C++ you have (which uses Win32 API for character encoding). hth, -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/20070302/998ccdf7/attachment.pgp From yianisn at gmail.com Fri Mar 2 09:18:28 2007 From: yianisn at gmail.com (Yianis Nikolaou) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML encoding In-Reply-To: <20070302134720.GA10970@karelia> References: <20070302103855.GA6699@karelia> <20070302134720.GA10970@karelia> Message-ID: thanks again! On 3/2/07, Boris Kolpackov wrote: > > Hi Yianis, > > Yianis Nikolaou writes: > > > I guess the standard Xerces library that I downloaded along with XSD > does > > not suport iso-8859-7 since I get an empty file when I call > > > > project (ofs, p, map, "ISO8859-7"); > > Not an exception? No I don't get an exception, just an empty XML file. > When I run xsd with the default char size I get an exception > > invalid_utf8_string from string.ixx when I use Greek characters in > string > > fields. > > Right, since char is expected to contain UTF-8. > > > > Questions: > > Q1: If Xerces recognized the iso8859-7 and I used wchars, then would I > get > > the correct output in iso8859-7 and not Unicode? > > Yes you should be able to. > > > Q2: If I compile XSD with XSD_USE_LCP defined, would I be able to enter > > Greek characters in standard char mode without getting the exception > > invalid_utf8_string? > > Yes, if you compiled the generated code with XSD_USE_LCP and your > system code page is iso8859-7 (or equivalent Windows name) then you > should be able to pass Greek characters in char. You may also be > able to save it as iso8859-7 (or Windows name) using Xerces-C++ > you have (which uses Win32 API for character encoding). > > > hth, > -boris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iQGVAwUBRegq6MiAKQuuCE8dAQJuNQv+LYLjv4LiwMnpejZ8DthOY67VBy4u2LTM > cPo1jGAGRtcH3q4WMrV+gfje+2yFkXB40Y/6hV83mEW1xJw2nxTC5OJRUzc2m3Cb > /GLJHBpeO4Q5GEHgbZflfltlIvoXqpyoV/0OpzZzHo1yjeqvmSENVqRMvE7gjIo5 > CdTnSAwJuDBviLpQVWrwmNk9eRLxEWlvS4FJeLjSPHtQi/FR+/corvwSHLva+z4U > j2mavcbuNJ5OtmMyNYHmgpXd4oYJZp166prQtRJsYgwMAXcIQh1DHfrzzx1EETQt > H89TlvCtABRFmtyVr7GVOvP72MyFLd6jl8YVacHPYrrZydl79Bv2hXduRUYa+806 > PHJ90MjgQc9HMoLIXCC+wujFv5FmZl8hcfb+Cc5RNx7m0ZGZUQYYzNVluqbwesRJ > XgnwMu+OXFNxPd4JJvPIjDJ4wpr81H7SBaaPJcPDqfu8O7K7ba64VVHWmUtP+J9v > e7gMJM832BSdWgkQR6Te3Jf6uocq3BU/ > =XUQD > -----END PGP SIGNATURE----- > > From boris at codesynthesis.com Fri Mar 2 09:49:55 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] XML encoding In-Reply-To: References: <20070302103855.GA6699@karelia> <20070302134720.GA10970@karelia> Message-ID: <20070302144955.GB10970@karelia> Hi Yianis, Yianis Nikolaou writes: > >Not an exception? > > No I don't get an exception, just an empty XML file. Ok, I will take a look into this for the next version. thanks, -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/20070302/9640c262/attachment.pgp From jitendra.sakhamuri at c-mci.com Fri Mar 2 12:57:37 2007 From: jitendra.sakhamuri at c-mci.com (Jitendra.Sakhamuri) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Need help for a Newbie... Message-ID: <004a01c75cf4$455914b0$6400a8c0@wiztechDlaptop> Hi, I am working on a poc for my client. I have found the xsd library very useful. I am trying to do something very trivial here and am running into issues. I have two XSDs. Query.xsd and Universal.xsd. Query.xsd imports the Universal.xsd. Query .xsd is compiled with xsd like xsd cxx-tree query.xsd everything is great. I go to the next step to compile and generate the code for Universal.xsd which is where I ran into issues. Here is how my Query.xsd and Universal.xsd looks like. Any help in this regard is greatly appreciated. Query.xsd Universal.xsd The error I am running into is Universal.xsd:5:46: error: unable to map XML Schema namespace 'http:/niem.gov/niem/universal/0.2' to C++ namespace Thanks Jitendra.Sakhamuri, Cell: (202)-297-3057. EMail: jitendra@c-mci.com Please visit http://www.c-mci.com Note: We respect your online privacy. This is not an unsolicited mail. Under Bill s.1618 Title III passed by the 105th US Congress this mail can not be considered Spam as long as we include contact information and a method to be removed from our mailing list. If you are not interested in receiving our e-mails then please reply and write 'REMOVE' -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.5/707 - Release Date: 3/1/2007 2:43 PM From boris at codesynthesis.com Fri Mar 2 13:27:44 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Need help for a Newbie... In-Reply-To: <004a01c75cf4$455914b0$6400a8c0@wiztechDlaptop> References: <004a01c75cf4$455914b0$6400a8c0@wiztechDlaptop> Message-ID: <20070302182744.GA12302@karelia> Hi, Jitendra.Sakhamuri writes: > The error I am running into is > Universal.xsd:5:46: error: unable to map XML Schema namespace > 'http://niem.gov/niem/universal/0.2' to C++ namespace It also says in the next line: Universal.xsd:5:46: info: use the --namespace-map or --namespace-regex option to provide custom mapping You can use, for example, this command line: xsd cxx-tree --namespace-map http://niem.gov/niem/universal/0.2=universal Universal.xsd I also suggest that you use the --morph-anonymous option. hth, -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/20070302/ff29c197/attachment.pgp From rlischner at proteus-technologies.com Fri Mar 2 16:25:03 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] typo in trees/types.txx Message-ID: Line 747 of libxsd/xsd/cxx/tree/types.txx: change "char byte" to "unsigned char byte". Otherwise the right shift can sign extend byte, causing undefined behavior when the array index is way, way, way bigger than 15. -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Fri Mar 2 16:35:43 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] typo in trees/types.txx In-Reply-To: References: Message-ID: <20070302213543.GA12906@karelia> Hi Ray, Ray Lischner writes: > Line 747 of libxsd/xsd/cxx/tree/types.txx: > change "char byte" to "unsigned char byte". Fixed, thanks! -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/20070302/d7d5ff93/attachment.pgp From boris at codesynthesis.com Fri Mar 2 16:53:13 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] typo in trees/types.txx In-Reply-To: References: Message-ID: <20070302215313.GB12906@karelia> Skipped content of type multipart/mixed-------------- 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/20070302/d65a59b7/attachment.pgp From rlischner at proteus-technologies.com Fri Mar 2 22:40:44 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Build & deployment Message-ID: To build xsd from source requires building Xerces from source, too. Apparently, the makefile links the Xerces library by naming the full path on the command line. As a result, the xsd program points to that path. This makes deployment difficult. I want xsd to point to just the tail name, and let LD_LIBRARY_PATH or ld.so.conf name the directory that contains xerces-c.so. (Ditto for Boost.) The way I build xsd now is to delete xsd/xsd, cd to xsd, run make -n > link.sh, edit the link.sh file by hand, and then run link.sh. That's not the way I want to build the program. -- Ray Lischner, Proteus Technologies P.S. I find it mildly annoying that running make -n from the top-level xsd-2.3.1 directory ignores the -n option and runs make for real. From boris at codesynthesis.com Mon Mar 5 09:52:21 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Build & deployment In-Reply-To: References: Message-ID: <20070305145221.GA22332@karelia> Hi Ray, Ray Lischner writes: > To build xsd from source requires building Xerces from source, too. > Apparently, the makefile links the Xerces library by naming the full > path on the command line. As a result, the xsd program points to that > path. This makes deployment difficult. I want xsd to point to just the > tail name, and let LD_LIBRARY_PATH or ld.so.conf name the directory > that contains xerces-c.so. (Ditto for Boost.) Actually, the -rpath option is used to embed all library paths into the xsd executable. This is only done for library dependencies that are configured in the "development" mode. The idea was that when you build things for development, you don't want to mess with LD_LIBRARY_PATH and -rpath is a good thing. When building a version for deployment you would use installed dependencies that don't get -rpath added to them. But this does not work well for XSD since one needs to use development build of Xerces-C++. I've added an option to build to disable the use of -rpath. Unfortunately, it required some backwards-incompatible changes so I had to bump the build interface version from 0.2 to 0.3. This, in turn, required changes in libcult, libfrontend-elements, libbackend-elements, libxsd-frontend, and xsd itself. We are planning to release the first beta of xsd-2.4.0 some time soon and these changes will be released then. If you would like to have this fix sooner, I can bundle all the necessary stuff into one archive and send it to you. Thanks for reporting this problem! > P.S. I find it mildly annoying that running make -n from the > top-level xsd-2.3.1 directory ignores the -n option and runs > make for real. I can explain what's going on here. Build is a non-recursive build system. The root level makefile includes makefiles for everything that needs to be built, including examples and tests. Examples and tests use the xsd translator to compile test schemas to C++. Auto-dependency generation technique is used to extract dependency information from those C++ files. So when you invoke GNU make from the root it tries to reads in all the makefiles, including dependency files which do not exist. Next make tries to build those dependencies and since they are included makefiles, make ignores the -n option while building them. But some of the dependencies are for xsd-generated C++ files, so make tries to build them (with -n ignored). But they, in turn, need the xsd translator so GNU make has no choice but to go ahead and build xsd for real. hth, -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/20070305/49a2c636/attachment.pgp From boris at codesynthesis.com Mon Mar 5 15:05:26 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] virtual insertion/extraction In-Reply-To: <20070228211503.GD14248@karelia> References: <20070228211503.GD14248@karelia> Message-ID: <20070305200526.GC22332@karelia> Hi Ray, I've been thinking about polymorphic insertion/extraction and it seems that hard-wired stream types supplied via the command line is the way to go. The not-so-clean consequence of this is that the user will also have to insert #include directives for the stream types via prolog options. Not sure if there is any way to avoid this. With this change we will have real insertion operators and extraction c-tors instead of templates so we can take an address that can be stored in a map. Let me know if you see any problems with this approach and your usage scenario. If everything seems fine I can give it a try tomorrow. thanks, -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/20070305/3a6c0059/attachment.pgp From mark.lofdahl at bigfoot.com Mon Mar 5 20:06:35 2007 From: mark.lofdahl at bigfoot.com (Mark Lofdahl) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] How to get element type from xsd Message-ID: <002301c75f8b$b1090640$6501a8c0@chip> I am trying to use DOM PSVI to get the XML Schema information for the DOM element and attribute nodes attached to the xsd tree. - I am using the "keep_dom" flag. - I am creating the DOMDocument myself and using "parser->setFeature(XMLUni::fgXercesDOMHasPSVIInfo, true)" so xerces will create the PSVI structures. - I am passing the DOMDocument to the main xsd parsing routine for my class. - I am calling the _node() method to retrieve the DOM node. - I am then calling getTypeInfo() or getInterface() to retrieve the PSVI information. However, I am not getting any PSVI information. When I step through the xsd and xerces code in debug, I notice that xsd is calling cloneNode() on the passed DOMDocument. I also notice that as nodes are cloned in xerces, it does *NOT* copy the fSchemaType member, which is the PSVI information. So because the node that is stored in the xsd tree is not the original DOMNode, but a copy, it no longer has the PSVI information. I know xerces is creating the PSVI information, because if I call doc->getDocumentElement()->getTypeInfo() on my DOMDocument, I get the correct PSVI information. Do you have any suggestions or workarounds to enable me to get the PSVI information? Thanks, Mark Lofdahl From boris at codesynthesis.com Tue Mar 6 02:21:04 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] How to get element type from xsd In-Reply-To: <002301c75f8b$b1090640$6501a8c0@chip> References: <002301c75f8b$b1090640$6501a8c0@chip> Message-ID: <20070306072104.GA24663@karelia> Hi Mark, Mark Lofdahl writes: > However, I am not getting any PSVI information. When I step through the xsd > and xerces code in debug, I notice that xsd is calling cloneNode() on the > passed DOMDocument. I also notice that as nodes are cloned in xerces, it > does *NOT* copy the fSchemaType member, which is the PSVI information. So > because the node that is stored in the xsd tree is not the original DOMNode, > but a copy, it no longer has the PSVI information. This is a known bug in Xerces-C++ that was fixed for the next version: http://issues.apache.org/jira/browse/XERCESC-1517 > Do you have any suggestions or workarounds to enable me to get the PSVI > information? I see two ways to address this: 1. Apply the fix to Xerces-C++ 2.7.0. Let me know if you need help extracting the patch (I have the SVN tree checked out). 2. If (1) is not acceptable, then you can change elements.txx in libxsd/xsd/cxx/xml/dom to call parser->setFeature(XMLUni::fgXercesDOMHasPSVIInfo, true) There are two places: around line 352 and 478. This will work because XSD does not make a copy of the DOM documents that it creates internally. hth, -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/20070306/df55ec76/attachment.pgp From mark.lofdahl at bigfoot.com Tue Mar 6 20:39:08 2007 From: mark.lofdahl at bigfoot.com (Mark Lofdahl) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] How to get element type from xsd In-Reply-To: <20070306072104.GA24663@karelia> References: <002301c75f8b$b1090640$6501a8c0@chip> <20070306072104.GA24663@karelia> Message-ID: <004001c76059$679592c0$6501a8c0@chip> Thanks! I'll give that a try. Would it be possible to add options/flags to XSD to allow the following: - have xsd call parser->setFeature(XMLUni::fgXercesDOMHasPSVIInfo, true) - have xsd not create a copy of a DOMDocument that is passed to it Thanks, Mark -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, March 05, 2007 11:21 PM To: Mark Lofdahl Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] How to get element type from xsd Hi Mark, Mark Lofdahl writes: > However, I am not getting any PSVI information. When I step through > the xsd and xerces code in debug, I notice that xsd is calling > cloneNode() on the passed DOMDocument. I also notice that as nodes are > cloned in xerces, it does *NOT* copy the fSchemaType member, which is > the PSVI information. So because the node that is stored in the xsd > tree is not the original DOMNode, but a copy, it no longer has the PSVI information. This is a known bug in Xerces-C++ that was fixed for the next version: http://issues.apache.org/jira/browse/XERCESC-1517 > Do you have any suggestions or workarounds to enable me to get the > PSVI information? I see two ways to address this: 1. Apply the fix to Xerces-C++ 2.7.0. Let me know if you need help extracting the patch (I have the SVN tree checked out). 2. If (1) is not acceptable, then you can change elements.txx in libxsd/xsd/cxx/xml/dom to call parser->setFeature(XMLUni::fgXercesDOMHasPSVIInfo, true) There are two places: around line 352 and 478. This will work because XSD does not make a copy of the DOM documents that it creates internally. hth, -boris From boris at codesynthesis.com Wed Mar 7 10:25:21 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] How to get element type from xsd In-Reply-To: <004001c76059$679592c0$6501a8c0@chip> References: <002301c75f8b$b1090640$6501a8c0@chip> <20070306072104.GA24663@karelia> <004001c76059$679592c0$6501a8c0@chip> Message-ID: <20070307152521.GA1622@karelia> Hi Mark, Mark Lofdahl writes: > Would it be possible to add options/flags to XSD to allow the following: > - have xsd call parser->setFeature(XMLUni::fgXercesDOMHasPSVIInfo, true) We don't want to duplicate the whole Xerces-C++ feature/property API. The policy it to provide equivalents to the most basic and widely- used features and properties while allowing one to set the XML-DOM stage in a completely customized way by providing a parsing function from DOMDocument. > - have xsd not create a copy of a DOMDocument that is passed to it This sounds like a reasonable thing to do even if it is not a work-around for a Xerces-C++ bug. I've added this to my TODO list. Hopefully it will get into the upcoming 2.4.0. hth, -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/20070307/9c5c6cec/attachment.pgp From rlischner at proteus-technologies.com Wed Mar 7 13:28:58 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] annotation documentation -> Doxygen comment Message-ID: The most useful new feature (to me, at least) would be to copy annotation documentation into Doxygen-formatted comments in the generated code. -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Wed Mar 7 13:28:44 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] annotation documentation -> Doxygen comment In-Reply-To: References: Message-ID: <20070307182844.GB1852@karelia> Hi Ray, Ray Lischner writes: > The most useful new feature (to me, at least) would be to copy > annotation documentation into Doxygen-formatted comments in the > generated code. This shouldn't be too difficult to do. I just need to find some time ;-). BTW, are you still interested in the polymorphic binary insertion/extraction? I send an email the other day with a brief overview of how I am planning to fix it. I would appreciate it if you could take look and check if there are any problems with this approach and your usage scenario. thanks, -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/20070307/feea35e8/attachment.pgp From Al.Niessner at jpl.nasa.gov Wed Mar 7 19:28:35 2007 From: Al.Niessner at jpl.nasa.gov (Al Niessner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Why this error? Message-ID: <1173313715.6680.130.camel@morte.jpl.nasa.gov> I am new to this product, but I have a pile of schema that I have been using with JaxB and generateDS for the Java and Python languages respectively. Hence, I think the XML Schema is mature enough that I can ignore it for now. Basically, I generated some C++ code with 'xsd cxx-tree ../../DescriptionLanguage/externalTool.xsd'. I then wrote a bunch of C++ code that looks very similar to my Java and Python code to parse some XML. It did not work at all. I get this error message: terminate called after throwing an instance of 'xsd::cxx::tree::parsing' what(): instance document parsing failed. I get the idea that the xml file might be wrong, so I parsed it with both Python and Java without error. I then visited the FAQ and added xml_schema::flags::dont_validate with no change. I then added the schema location to the XML file with no change. Since the test code and XML file are small and simple I have attach them. If you want to see more I can produce it, but did not want to bloat this email overly much. Thanks for any and all help in advance. -- Al Niessner 818.354.0859 All opinions stated above are mine and do not necessarily reflect those of JPL or NASA. -------- | dS | >= 0 -------- -------------- next part -------------- A non-text attachment was scrubbed... Name: msg.xml Type: application/xml Size: 165 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070307/b96125d6/msg.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: test.cc Type: text/x-c++src Size: 602 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070307/b96125d6/test.cc From boris at codesynthesis.com Thu Mar 8 02:42:07 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Why this error? In-Reply-To: <1173313715.6680.130.camel@morte.jpl.nasa.gov> References: <1173313715.6680.130.camel@morte.jpl.nasa.gov> Message-ID: <20070308074207.GA3309@karelia> Hi Al, Al Niessner writes: > I then wrote a bunch of C++ code that looks very similar to my Java and > Python code to parse some XML. It did not work at all. I get this error > message: > > terminate called after throwing an instance of > 'xsd::cxx::tree::parsing' > what(): instance document parsing failed. It is usually a good idea to catch the exception and print it to get a better idea about what went wrong. Here is what I did: try { msg = ExternalTool (ss, xml_schema::flags::dont_validate); } catch (const xml_schema::exception& e) { std::cerr << e << std::endl; } After this change I got a more descriptive error: 1:13 error: Unterminated processing instruction For some reason it does not like your XML declaration () since that's the only processing instruction in this document. Because you are first reading the contents of the file into a string buffer, let's check if the XML is still good in that buffer. I added std::cout << fullText << std::endl; Before the above code. It prints: ... The XML declaration does not look right anymore: all whitespaces are gone. Looking at the code that fills the buffer we can see what's going on: while (!fin.eof()) { fin >> buffer; fullText += buffer; } fin >> buffer reads one word at a time, stripping leading and trailing whitespaces. Here is a version that reads in an exact copy of the file. It is also a bit more efficient: fin.open ("msg.xml", std::ios::in | std::ios::ate); std::size_t size (fin.tellg ()); fin.seekg (0, std::ios::beg); fullText.reserve (size); while (size != 0 && !fin.eof ()) { char buf[1024]; fin.read (buf, size < sizeof (buf) ? size : sizeof (buf)); std::size_t n = fin.gcount (); fullText.append (buf, n); size -= n; } fin.close(); After making this change the file parses without any problems. You probably know that, but just in case, you can parse the file directly without first reading it into a buffer. Both: msg = ExternalTool ("msg.xml", xml_schema::flags::dont_validate); and fin.open ("msg.xml"); msg = ExternalTool (fin, xml_schema::flags::dont_validate); fin.close(); work. hth, -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/20070308/0cc308cd/attachment.pgp From Al.Niessner at jpl.nasa.gov Thu Mar 8 16:48:11 2007 From: Al.Niessner at jpl.nasa.gov (Al Niessner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Why this error? In-Reply-To: <20070308074207.GA3309@karelia> References: <1173313715.6680.130.camel@morte.jpl.nasa.gov> <20070308074207.GA3309@karelia> Message-ID: <1173390491.6680.155.camel@morte.jpl.nasa.gov> Message does not help me much more: :1:13 error: Unterminated processing instruction If it is referring to the XML, all the tags that I see are terminated. Does it mean something different to you? On Thu, 2007-03-08 at 09:42 +0200, Boris Kolpackov wrote: > Hi Al, > > Al Niessner writes: > > > I then wrote a bunch of C++ code that looks very similar to my Java and > > Python code to parse some XML. It did not work at all. I get this error > > message: > > > > terminate called after throwing an instance of > > 'xsd::cxx::tree::parsing' > > what(): instance document parsing failed. > > It is usually a good idea to catch the exception and print it to get > a better idea about what went wrong. Here is what I did: > > try > { > msg = ExternalTool (ss, xml_schema::flags::dont_validate); > } > catch (const xml_schema::exception& e) > { > std::cerr << e << std::endl; > } > > After this change I got a more descriptive error: > > 1:13 error: Unterminated processing instruction > > For some reason it does not like your XML declaration > () since that's > the only processing instruction in this document. > > Because you are first reading the contents of the file into a string > buffer, let's check if the XML is still good in that buffer. I added > > std::cout << fullText << std::endl; > > Before the above code. It prints: > > ... > > The XML declaration does not look right anymore: all whitespaces are > gone. Looking at the code that fills the buffer we can see what's > going on: > > while (!fin.eof()) > { > fin >> buffer; > fullText += buffer; > } > > fin >> buffer reads one word at a time, stripping leading and trailing > whitespaces. Here is a version that reads in an exact copy of the file. > It is also a bit more efficient: > > fin.open ("msg.xml", std::ios::in | std::ios::ate); > std::size_t size (fin.tellg ()); > fin.seekg (0, std::ios::beg); > > fullText.reserve (size); > > while (size != 0 && !fin.eof ()) > { > char buf[1024]; > fin.read (buf, size < sizeof (buf) ? size : sizeof (buf)); > std::size_t n = fin.gcount (); > > fullText.append (buf, n); > size -= n; > } > > fin.close(); > > After making this change the file parses without any problems. > You probably know that, but just in case, you can parse the file > directly without first reading it into a buffer. Both: > > msg = ExternalTool ("msg.xml", xml_schema::flags::dont_validate); > > and > > fin.open ("msg.xml"); > msg = ExternalTool (fin, xml_schema::flags::dont_validate); > fin.close(); > > work. > > > hth, > -boris -- Al Niessner 818.354.0859 All opinions stated above are mine and do not necessarily reflect those of JPL or NASA. -------- | dS | >= 0 -------- From Al.Niessner at jpl.nasa.gov Thu Mar 8 18:02:09 2007 From: Al.Niessner at jpl.nasa.gov (Al Niessner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Why this error? In-Reply-To: <1173390491.6680.155.camel@morte.jpl.nasa.gov> References: <1173313715.6680.130.camel@morte.jpl.nasa.gov> <20070308074207.GA3309@karelia> <1173390491.6680.155.camel@morte.jpl.nasa.gov> Message-ID: <1173394929.23587.6.camel@morte.jpl.nasa.gov> This seems to be an error propagating up from xceres-c 2.7. It does not something about the line I have no idea what it thinks is wrong, but from the message I would guess that its failure point is '=' at column 13. Given my quality at parsing XML, I would say that it is a valid line of XML. JaxB and generateDS would agree. On Thu, 2007-03-08 at 13:48 -0800, Al Niessner wrote: > Message does not help me much more: > > :1:13 error: Unterminated processing instruction > > If it is referring to the XML, all the tags that I see are terminated. > Does it mean something different to you? > > On Thu, 2007-03-08 at 09:42 +0200, Boris Kolpackov wrote: > > Hi Al, > > > > Al Niessner writes: > > > > > I then wrote a bunch of C++ code that looks very similar to my Java and > > > Python code to parse some XML. It did not work at all. I get this error > > > message: > > > > > > terminate called after throwing an instance of > > > 'xsd::cxx::tree::parsing' > > > what(): instance document parsing failed. > > > > It is usually a good idea to catch the exception and print it to get > > a better idea about what went wrong. Here is what I did: > > > > try > > { > > msg = ExternalTool (ss, xml_schema::flags::dont_validate); > > } > > catch (const xml_schema::exception& e) > > { > > std::cerr << e << std::endl; > > } > > > > After this change I got a more descriptive error: > > > > 1:13 error: Unterminated processing instruction > > > > For some reason it does not like your XML declaration > > () since that's > > the only processing instruction in this document. > > > > Because you are first reading the contents of the file into a string > > buffer, let's check if the XML is still good in that buffer. I added > > > > std::cout << fullText << std::endl; > > > > Before the above code. It prints: > > > > ... > > > > The XML declaration does not look right anymore: all whitespaces are > > gone. Looking at the code that fills the buffer we can see what's > > going on: > > > > while (!fin.eof()) > > { > > fin >> buffer; > > fullText += buffer; > > } > > > > fin >> buffer reads one word at a time, stripping leading and trailing > > whitespaces. Here is a version that reads in an exact copy of the file. > > It is also a bit more efficient: > > > > fin.open ("msg.xml", std::ios::in | std::ios::ate); > > std::size_t size (fin.tellg ()); > > fin.seekg (0, std::ios::beg); > > > > fullText.reserve (size); > > > > while (size != 0 && !fin.eof ()) > > { > > char buf[1024]; > > fin.read (buf, size < sizeof (buf) ? size : sizeof (buf)); > > std::size_t n = fin.gcount (); > > > > fullText.append (buf, n); > > size -= n; > > } > > > > fin.close(); > > > > After making this change the file parses without any problems. > > You probably know that, but just in case, you can parse the file > > directly without first reading it into a buffer. Both: > > > > msg = ExternalTool ("msg.xml", xml_schema::flags::dont_validate); > > > > and > > > > fin.open ("msg.xml"); > > msg = ExternalTool (fin, xml_schema::flags::dont_validate); > > fin.close(); > > > > work. > > > > > > hth, > > -boris -- Al Niessner 818.354.0859 All opinions stated above are mine and do not necessarily reflect those of JPL or NASA. -------- | dS | >= 0 -------- From boris at codesynthesis.com Fri Mar 9 01:41:44 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Why this error? In-Reply-To: <1173394929.23587.6.camel@morte.jpl.nasa.gov> References: <1173313715.6680.130.camel@morte.jpl.nasa.gov> <20070308074207.GA3309@karelia> <1173390491.6680.155.camel@morte.jpl.nasa.gov> <1173394929.23587.6.camel@morte.jpl.nasa.gov> Message-ID: <20070309064144.GA9020@karelia> Hi Al, Al Niessner writes: > This seems to be an error propagating up from xceres-c 2.7. It does not > something about the line > > This is the XML declaration as found in the XML file: And this one is as found in the fullText buffer: Do you see any difference (there are no spaces in the second version)? The first is valid while the second is not. The problem is with the way you read in the XML in this loop: while (!fin.eof()) { fin >> buffer; fullText += buffer; } The fin >> buffer extracts words and ignores whitespaces. As a result, you end up with the mangled XML declaration above. I provided a modified version of this loop in my first reply to this thread. It reads in an exact code copy of the XML file, including whitespaces. hth, -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/20070309/b3c202f6/attachment.pgp From mark at digitalfountain.com Fri Mar 9 12:34:52 2007 From: mark at digitalfountain.com (Mark Watson) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Groups and AttributeGroups In-Reply-To: <20070208203431.GA27302@karelia> Message-ID: Hi Boris, Returning to this question. I have the templates approach working. However, I have some 20-30 attributes/elements defined in 7 or 8 groups which then appear in various combinations in 10 or so different types and the result is hundreds and hundreds of lines of generated code. The templates approach works, but it feels a little unmanageable at this scale. What's the chance that some mechanism to factor out groups into common base classes might make it into some future xsd release ? I think the multiple inheritance might be a price worth paying for the simplification that would come from representing the group structure of the schema within the C++ code. However, I didn't understand the other technical difficulty you mentioned. Best regards, Mark Watson On 2/8/07 12:34 PM, "Boris Kolpackov" wrote: > Hi Mark, > > Mark Watson writes: > >> Is there a way to avoid duplication of code generated for groups and >> attributeGroups when they are included in multiple elements ? >> >> When an attribubuteGroup is used within two distinct elements, then separate >> code seems to be generated in each element for the individual attributes in >> the group. Is it possible to generate a class for the attribute group as a >> whole and include this as a contained class (or super-class, if the >> resulting multiple inheritance is not too much of a problem) within each >> element which has the group ? > > There is no such facility at the moment. Groups are really a syntactic > sugar that allows you to "copy" the same content into several types > while keeping things manageable. The content of a group a set of > element or attributes and as such is mapped to a bunch of functions > that do not really result in much object code (most of them are inline > and one line long). There are also technical difficulties in factoring > a group out as a base class since the type can also have a real base > type which would require multiple virtual inheritance and non-trivial > parsing delegation to handle properly. > > >> This would make handling the resulting objects easier, as a single piece of >> code could handle the common attributes across the various objects which use >> those attributes. > > You can achieve this with a function template. Suppose you have the > following group: > > > > > > > > > You could then write the following function template: > > template > void process_g (X& x) > { > cout << "foo: " << x.foo () << endl > << "bar: " << x.bar () << endl; > } > > And call it on any instance of a type that embeds group g. > > >> Alternatively, is there a different Schema construction instead of >> attributeGroup which could achieve the same thing. I thought of defining a >> type with the attributes and deriving the other types from that, but as I >> have several attribute groups to play with and (unless I missed something) >> XML does not support multiple inheritance (perhaps wisely). > > The inheritance mechanism is your best bet. White XML Schema does not > support multiple inheritance, you can always create a base that has > two or more groups in it. The drawback of this approach is that you > won't be able to have a single base for each group which you could > handle generically. For example, if you have three groups, G1, G2, > and G3, then you will need two base classes that contain, say, G1: > B1={G1,G2} and B2={G1,G3}. As a result you will need write two > functions to handle group G1: one that takes B1 and the other that > takes B2. Overall, I think the function template approach is cleaner > and less verbose. > > > hth, > -boris From mark.lofdahl at bigfoot.com Sat Mar 10 13:25:04 2007 From: mark.lofdahl at bigfoot.com (Mark Lofdahl) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] How to get element type from xsd In-Reply-To: <20070306072104.GA24663@karelia> References: <002301c75f8b$b1090640$6501a8c0@chip> <20070306072104.GA24663@karelia> Message-ID: <002f01c76341$6e011fe0$6401a8c0@chip> Hi, I changed elements.txx as described below, but am still having problems. It appears that XSD is still making a copy of the DOM Document that it creates internally. Am I missing something? Thanks, Mark -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, March 05, 2007 11:21 PM To: Mark Lofdahl Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] How to get element type from xsd Hi Mark, Mark Lofdahl writes: > However, I am not getting any PSVI information. When I step through > the xsd and xerces code in debug, I notice that xsd is calling > cloneNode() on the passed DOMDocument. I also notice that as nodes are > cloned in xerces, it does *NOT* copy the fSchemaType member, which is > the PSVI information. So because the node that is stored in the xsd > tree is not the original DOMNode, but a copy, it no longer has the PSVI information. This is a known bug in Xerces-C++ that was fixed for the next version: http://issues.apache.org/jira/browse/XERCESC-1517 > Do you have any suggestions or workarounds to enable me to get the > PSVI information? I see two ways to address this: 1. Apply the fix to Xerces-C++ 2.7.0. Let me know if you need help extracting the patch (I have the SVN tree checked out). 2. If (1) is not acceptable, then you can change elements.txx in libxsd/xsd/cxx/xml/dom to call parser->setFeature(XMLUni::fgXercesDOMHasPSVIInfo, true) There are two places: around line 352 and 478. This will work because XSD does not make a copy of the DOM documents that it creates internally. hth, -boris From boris at codesynthesis.com Sat Mar 10 15:27:05 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] How to get element type from xsd In-Reply-To: <002f01c76341$6e011fe0$6401a8c0@chip> References: <002301c75f8b$b1090640$6501a8c0@chip> <20070306072104.GA24663@karelia> <002f01c76341$6e011fe0$6401a8c0@chip> Message-ID: <20070310202705.GA16702@karelia> Hi Mark, Mark Lofdahl writes: > I changed elements.txx as described below, but am still having problems. It > appears that XSD is still making a copy of the DOM Document that it creates > internally. Am I missing something? > I thought it didn't copy internally created DOM documents but I just checked and now I see it does. Sorry about that. I guess the easiest way to fix this is to do the right thing and provide a flag for the tree to assume DOM ownership. I will try to make the changes tomorrow and build a pre-release binary for you. Which platform/package are you using? hth, -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/20070310/904eb5e7/attachment.pgp From rlischner at proteus-technologies.com Mon Mar 12 11:26:58 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] abuse Message-ID: The implemenentation of has the potential for abuse. Suppose I have a schema with the following: The generated class X has three optional members: a, b, and c. The problem is that I can set all three members: X x; x.a(20); x.b(3.14); x.c("hello"); with the nonsensical result that the "choice" has all three values, not only one. I wish the code were more resilient to programmer error. Calling x.b(2.718) should result in a call to x.a().reset() and x.c().reset(). Or the implementation of could switch to a union, with a generated enumeration to specify which union member is valid. Meanwhile, I'm open to suggestions for the best way to ensure that programmers do not inadvertently create invalid objects. -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Mon Mar 12 15:31:11 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Groups and AttributeGroups In-Reply-To: References: <20070208203431.GA27302@karelia> Message-ID: <20070312193111.GA407@karelia> Hi Mark, Mark Watson writes: > Returning to this question. I have the templates approach working. However, > I have some 20-30 attributes/elements defined in 7 or 8 groups which then > appear in various combinations in 10 or so different types and the result is > hundreds and hundreds of lines of generated code. The templates approach > works, but it feels a little unmanageable at this scale. What exactly are you concerned here with? Is it the object code size that results from the generated code? Is it the object code size that results from the function templates? Note that, in this case, it does not make much sense to count the lines of generated code because all the generated accessors/modifiers (pretty much what constitutes a group in the generate code) are inline one-liners. > What's the chance that some mechanism to factor out groups into common > base classes might make it into some future xsd release ? I am not convinced it is a good idea. The only benefit I see is the ability to handle group generically without using things like templates. There are a number of serious disadvantages though, including significant complications in the generated code logic and increased object code size. To be specific, right now each element/attribute in a type results in the following three major parts in the generated code: (1) Inline accessors/modifiers. (2) A small piece of code in the c-tor. (3) A small piece of code in the parsing function. These are generated in every class that references a group. With the base class approach we will need exactly the same code in the common base class plus the following in each class that references the group: (1) A small piece of code that forwards arguments to the base c-tor. (2) A significantly more complicated parsing code that figures our when and what to delegate to the group classes. I think (1) here and (2) above will be about the same. I expect (2) to result in more code than (3) above. Plus you get all the extra (2) and (3) above for each group class. hth, -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/20070312/2fce4644/attachment.pgp From boris at codesynthesis.com Tue Mar 13 15:50:11 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] abuse In-Reply-To: References: Message-ID: <20070313195011.GB2597@karelia> Hi Ray, Ray Lischner writes: > > > > > > > > > The generated class X has three optional members: a, b, and c. The > problem is that I can set all three members: > > X x; > x.a(20); > x.b(3.14); > x.c("hello"); > > with the nonsensical result that the "choice" has all three values, > not only one. I wish the code were more resilient to programmer > error. This is part of a bigger issue that all data binding tools have to deal with. It boils down to whether to recreate the schema structure with an "unnatural" access API or to "flatten" the structure and generate an easy to use but sometimes dangerous API. We decided to go with the flat, easy, and dangerous ;-). I am not sure this is the right way. I am actually not even sure there is a right may. It appears to depend heavily on the schema design, i.e., a document-centric schemas normally have a lot of structure and would probably be better off with a structured API while data-centric schemas are normally simpler and do not rely on relative ordering of elements, etc. In this case the flat API is probably a better choice. > Or the implementation of could switch to a union, with > a generated enumeration to specify which union member is valid. Yes, this is one possibility and it will work pretty well for the example you gave. But consider something like this (quite a common pattern, BTW): Here, is used to say "at least on of to|cc|bcc in any order". Let's see how this can be mapped to a union. Because we have a sequence of choices (maxOccurs="unbounded"), we will need to generate a nested type for this compositor, something along these lines: struct email { struct choice_element_type { enum tag { to_tag, cc_tag, bcc_tag }; tag which (); string to (); string cc (); string bcc (); }; typedef sequence choice_type; choice_type& choice (); string subject (); string body (); ... }; Note how we had to invent a lot of names that are not really found in the schema -- they are all candidates for name conflicts. While this API preserve the structure of the content, the flat API is probably preferable in this case since all one needs is a list of to's, cc's and bcc's. > Meanwhile, I'm open to suggestions for the best way to ensure > that programmers do not inadvertently create invalid objects. At the moment there is no way to enforce this with the interface so the only way I can see is to educate them about the limitations. If there was a possibility to choose between structured and flat APIs, would you switch to the structured even if it complicates your code quite a bit? thanks, -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/20070313/808c6e79/attachment.pgp From boris at codesynthesis.com Tue Mar 13 16:28:33 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Re: question re. linking In-Reply-To: <6868F396F5637540AE9D274CC90BD88F041C28EB@FNEX01.fishsec.com> References: <6868F396F5637540AE9D274CC90BD88F041C28EB@FNEX01.fishsec.com> Message-ID: <20070313202833.GC2597@karelia> Hi Scott, Miller, Scott (Kansas City) writes: > I've subscribed to xsd-users forum to search... Please also post your technical questions to this mailing list. This way others will be able to find the answers to similar questions by searching the archives. I've CC'ed xsd-users to my reply. > Until then...I'm getting "error LNK2005" error about code already > existing in an existing .obj (the .obj created when I compile the > generated .cpp file). In my application .cpp I get link error > (application.cpp includes the generated .h file). What's > recommended approach for ensuring the code only gets generated > once? I think you have the same schema constructs (ApplicationsType?) defined in two separate schemas. The way to fix this is to move common code to a separate schema and then include or import it into the original schemas. hth, -boris [The rest of the message follows for context.] > > > > Here's full error: > > > > ApplicationServer error LNK2005: "class std::basic_ostream > & > __cdecl xml::firemon::operator<<(class std::basic_ostream > &,class > xml::firemon::ApplicationsType const &)" > (??6firemon@xml@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@AAV23@ABVApplicationsType@01@@Z) > already defined in EnumerateConfigurationsRequest.obj > > > > Here's include from application code: > > > > #include "../../Generated/EnumerateConfigurationsRequest.h" > > using xml::firemon::EnumerateConfigurationsRequest; > > using xml::firemon::EnumerateConfigurationsRequestType; > > using xml::firemon::ApplicationsType; > > using xml::firemon::ApplicationType; > > using xml::firemon::ConfigurationGroupsType; > > using xml::firemon::ConfigurationGroupType; > > using xml::firemon::DateTimeRangeType; > > > > Been in Java land for quite awhile... J -------------- 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/20070313/fc31e261/attachment.pgp From boris at codesynthesis.com Tue Mar 13 16:51:56 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] abuse In-Reply-To: References: <20070313195011.GB2597@karelia> Message-ID: <20070313205156.GD2597@karelia> Hi Ray, I've CC'ed xsd-users back in so that this will get archived and available to others. Ray Lischner writes: > You present a convincing argument for the flat choice. Perhaps > one solution is for the generated code to automatically call > reset() for the other choices, e.g., > > void email::to(const to::type& to) > { > this->_xsd_to_.set(to); > this->_xsd_cc_.reset(); > this->_xsd_bcc_.reset(); > } This can certainly be done. Though it will only work for that has maxOccurs == "1" and is not nested in another compositor with maxOccurs > "1". Otherwise the choice members are mapped to sequences and the fix does not apply anymore. But I guess this is better than nothing. I've added it to my TODO list. Thanks for the suggestion! -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/20070313/67f7477a/attachment.pgp From rlischner at proteus-technologies.com Wed Mar 14 10:28:37 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] abuse References: Message-ID: Upon further reflection, I realize that I was wrong. Code Synthesis does not enforce other schema restrictions, such as maxOccurs. There is no reason to treat differently or specially. -- Ray Lischner, Proteus Technologies ________________________________ From: xsd-users-bounces@codesynthesis.com on behalf of Ray Lischner Sent: Mon 3/12/2007 11:26 AM To: xsd-users@codesynthesis.com Subject: [xsd-users] abuse The implemenentation of has the potential for abuse. Suppose I have a schema with the following: The generated class X has three optional members: a, b, and c. The problem is that I can set all three members: X x; x.a(20); x.b(3.14); x.c("hello"); with the nonsensical result that the "choice" has all three values, not only one. I wish the code were more resilient to programmer error. Calling x.b(2.718) should result in a call to x.a().reset() and x.c().reset(). Or the implementation of could switch to a union, with a generated enumeration to specify which union member is valid. Meanwhile, I'm open to suggestions for the best way to ensure that programmers do not inadvertently create invalid objects. -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Wed Mar 14 11:00:02 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] abuse In-Reply-To: References: Message-ID: <20070314150002.GA5934@karelia> Hi Ray, Ray Lischner writes: > Upon further reflection, I realize that I was wrong. Code Synthesis > does not enforce other schema restrictions, such as maxOccurs. There > is no reason to treat differently or specially. I think there is. maxOccurs values other than "1" or "unbounded" are very rare[1]. Both "1" and "unbounded" are supported by the interface. On the other hand, is quite common and adding some extra safety would be a good idea, I think. 1. Some schema processors exhibit very poor performance with maxOccurs values greater than "1" but less than "unbounded". The fact that vendors think this is acceptable confirms that this case is not widely used. hth, -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/20070314/8a88d32d/attachment.pgp From mark at digitalfountain.com Wed Mar 14 15:03:42 2007 From: mark at digitalfountain.com (Mark Watson) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] Groups and AttributeGroups In-Reply-To: <20070312193111.GA407@karelia> Message-ID: Hi Boris, It wasn't object code size that I was concerned about. Rather the size of the generated code and thus the difficulty in browsing/understanding that. You could reasonably say that I should never need to look at the generated code, since I should know how to manipulate the objects from the mapping rules, and so the issue will go away as I become more familiar with those mapping rules. Anyway, you answered my question and I could agree that the behind-the-scenes complexity you describe may not be justified for the resulting simplifications in the generated interface. Best regards, Mark On 3/12/07 12:31 PM, "Boris Kolpackov" wrote: > Hi Mark, > > Mark Watson writes: > >> Returning to this question. I have the templates approach working. However, >> I have some 20-30 attributes/elements defined in 7 or 8 groups which then >> appear in various combinations in 10 or so different types and the result is >> hundreds and hundreds of lines of generated code. The templates approach >> works, but it feels a little unmanageable at this scale. > > What exactly are you concerned here with? Is it the object code size > that results from the generated code? Is it the object code size > that results from the function templates? Note that, in this case, > it does not make much sense to count the lines of generated code > because all the generated accessors/modifiers (pretty much what > constitutes a group in the generate code) are inline one-liners. > > >> What's the chance that some mechanism to factor out groups into common >> base classes might make it into some future xsd release ? > > I am not convinced it is a good idea. The only benefit I see is > the ability to handle group generically without using things > like templates. There are a number of serious disadvantages > though, including significant complications in the generated > code logic and increased object code size. > > To be specific, right now each element/attribute in a type > results in the following three major parts in the generated > code: > > (1) Inline accessors/modifiers. > > (2) A small piece of code in the c-tor. > > (3) A small piece of code in the parsing function. > > These are generated in every class that references a group. With > the base class approach we will need exactly the same code in the > common base class plus the following in each class that references > the group: > > (1) A small piece of code that forwards arguments to the base c-tor. > > (2) A significantly more complicated parsing code that figures > our when and what to delegate to the group classes. > > > I think (1) here and (2) above will be about the same. I expect > (2) to result in more code than (3) above. Plus you get all the > extra (2) and (3) above for each group class. > > > hth, > -boris From rlischner at proteus-technologies.com Wed Mar 14 15:28:46 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:53 2009 Subject: [xsd-users] bug in types.hxx line 337 Message-ID: I have to leave work now, so I don't have much time, but I wanted to report this as soon as possible. Line 337 of xsd/cxx/tree/types.hxx calls xercesc::Base64::encode to encode a base64_binary value. The result is stored in an auto_array object. The problem is that Base64::encode calls operator new to allocate the memory, and auto_array uses delete[] to free the memory. I ran a program under valgrind, which reported the mismatch. -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Wed Mar 14 15:10:45 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Groups and AttributeGroups In-Reply-To: References: <20070312193111.GA407@karelia> Message-ID: <20070314191045.GB5934@karelia> Hi Mark, Mark Watson writes: > It wasn't object code size that I was concerned about. Rather the size of > the generated code and thus the difficulty in browsing/understanding that. I don't know about you but I would probably prefer to have all my accessors/modifiers to be present at one place (class definition) instead of looking in a dozen of base classes. > You could reasonably say that I should never need to look at the generated > code, since I should know how to manipulate the objects from the mapping > rules, and so the issue will go away as I become more familiar with those > mapping rules. We have no problem with you looking at the generated code ;-). That's why we try to make it as close to hand-written as possible. I think some people like to "know" what is being generated while other like to look it up. Also in order to "know" one may need to look at the definition in the schema so it could actually be easier to just check the generated code. In the next version of XSD we are planning to rework the code generated for accessors and modifiers which should also result in fewer lines of source code. hth, -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/20070314/e34004ca/attachment.pgp From mark at digitalfountain.com Wed Mar 14 15:35:32 2007 From: mark at digitalfountain.com (Mark Watson) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Parser still fetches schema with xsd::flags::don =?iso-8859-1?q?=B9?= t_validate Message-ID: Hi, I have an XML instance document which references its schema via HTTP. Although I have set xsd::flags::dont_validate, the parser still fetches the schema over HTTP. This is the default xerces behaviour as described in http://xml.apache.org/xerces-c/faq-parse.html#faq-28 Is there a way to disable this from xsd ? I know I could parse the document to a Xerces DOM document myself (cf http://wiki.codesynthesis.com/Tree/FAQ), in which case I can disable the feature myself, but aside from this I have no reason to be concerned about the DOM and Xerces, so it would be nice to do this from the xsd interface. Regards, Mark From boris at codesynthesis.com Wed Mar 14 15:40:01 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Parser =?iso-8859-1?Q?stil?= =?iso-8859-1?Q?l_fetches_schema_with_xsd=3A=3Aflags=3A=3Adon_?= =?iso-8859-1?Q?=B9?= t_validate In-Reply-To: References: Message-ID: <20070314194001.GC5934@karelia> Hi Mark, Mark Watson writes: > I have an XML instance document which references its schema via HTTP. > Although I have set xsd::flags::dont_validate, the parser still fetches the > schema over HTTP. This is the default xerces behaviour as described in > http://xml.apache.org/xerces-c/faq-parse.html#faq-28 Is it fetching DTD or XML Schema? The FAQ only talks about DTDs and it makes sense to fetch (and parse) them by default since they are used for things other than validation (entities, default attributes, etc). I don't see a reason to fetch XML Schema though since it is only used for validation. thanks, -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/20070314/f851d11f/attachment.pgp From boris at codesynthesis.com Wed Mar 14 16:33:09 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] bug in types.hxx line 337 In-Reply-To: References: Message-ID: <20070314203309.GD5934@karelia> Hi Ray, Ray Lischner writes: > Line 337 of xsd/cxx/tree/types.hxx calls xercesc::Base64::encode > to encode a base64_binary value. The result is stored in an > auto_array object. The problem is that Base64::encode calls > operator new to allocate the memory, and auto_array uses delete[] > to free the memory. I ran a program under valgrind, which reported > the mismatch. I could verify this with valgrind on the test/cxx/tree/built-in test. The fix can be obtained here: http://codesynthesis.com/~boris/tmp/xsd-2.3.1-array-delete.patch With this fix the test passes without any errors. Thanks for tracking this down! -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/20070314/d343751f/attachment.pgp From mark at digitalfountain.com Wed Mar 14 17:27:28 2007 From: mark at digitalfountain.com (Mark Watson) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Parser still fetches schema with xsd::flags::don =?ISO-8859-1?B?uSA=?=t_validate In-Reply-To: <20070314194001.GC5934@karelia> Message-ID: Sorry, I meant DTD. ...Mark On 3/14/07 12:40 PM, "Boris Kolpackov" wrote: > Hi Mark, > > Mark Watson writes: > >> I have an XML instance document which references its schema via HTTP. >> Although I have set xsd::flags::dont_validate, the parser still fetches the >> schema over HTTP. This is the default xerces behaviour as described in >> http://xml.apache.org/xerces-c/faq-parse.html#faq-28 > > Is it fetching DTD or XML Schema? The FAQ only talks about DTDs and > it makes sense to fetch (and parse) them by default since they are > used for things other than validation (entities, default attributes, > etc). I don't see a reason to fetch XML Schema though since it is > only used for validation. > > > thanks, > -boris From boris at codesynthesis.com Wed Mar 14 17:27:29 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Parser still fetches schema with xsd::flags::dont_validate In-Reply-To: References: <20070314194001.GC5934@karelia> Message-ID: <20070314212729.GF5934@karelia> Hi Mark, Mark Watson writes: > Sorry, I meant DTD. Ok, that's what I thought. I don't think it will be the right thing to do to disable this feature when the dont_validate flag is passed for reasons outlined in the FAQ entry. So, I am afraid, you will need to set up a custom XML->DOM stage to disable this behavior. hth, -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/20070314/a30dd1e0/attachment.pgp From beddoes at intient.com Wed Mar 14 18:32:51 2007 From: beddoes at intient.com (Bradley Beddoes) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Customizing Types problem Message-ID: <45F87813.6000400@intient.com> Hi, I have been working on some customized types the past few days and have run into an issue which I would like to get some advice on. I have two schema one which references the other, both with unique namespaces. However both define a unique type called AttributeValueType. I wanted to customize only the version presented in the second schema. I have achieved this now by not defining a customized type at all and manually removing and re-implementing the generated code for the second type. Any ideas how I can make the --customized-type switch specifically target only the definition in the schema I am interested in? regards, Bradley -- Bradley Beddoes Lead Software Architect http://intient.com Intient - "Open Source, Open Standards" From rlischner at proteus-technologies.com Wed Mar 14 23:11:09 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Customizing Types problem References: <45F87813.6000400@intient.com> Message-ID: > Any ideas how I can make the --customized-type switch specifically > target only the definition in the schema I am interested in? I do it by keeping the two schemas in separate files, and supply the --custom-type switch when compiling only the file that contains that type. -- Ray Lischner, Proteus Technologies From beddoes at intient.com Wed Mar 14 23:42:50 2007 From: beddoes at intient.com (Bradley Beddoes) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Customizing Types problem In-Reply-To: References: <45F87813.6000400@intient.com> Message-ID: <45F8C0BA.4030400@intient.com> Yes but in this instance one relies on components from the other so both must be supplied unfortunately. Ray Lischner wrote: > > Any ideas how I can make the --customized-type switch specifically > > target only the definition in the schema I am interested in? > > I do it by keeping the two schemas in separate files, and supply the > --custom-type switch when compiling only the file that contains that type. > -- > Ray Lischner, Proteus Technologies > -- Bradley Beddoes Lead Software Architect http://intient.com Intient - "Open Source, Open Standards" From boris at codesynthesis.com Thu Mar 15 03:08:42 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Customizing Types problem In-Reply-To: <45F8C0BA.4030400@intient.com> References: <45F87813.6000400@intient.com> <45F8C0BA.4030400@intient.com> Message-ID: <20070315070842.GA10063@karelia> Hi Bradley, Bradley Beddoes writes: > Yes but in this instance one relies on components from the other so > both must be supplied unfortunately. I think Ray's suggestion should work. If one relies on the other then there must be an import statement. The --custom-type option only affects the target namespace of the schema being compiled. For example, if you have schema foo.xsd and bar.xsd. foo.xsd imports bar.xsd. Both of them define say, my_type. If you do: $ xsd cxx-tree --custom-type my_type foo.xsd $ xsd cxx-tree bar.xsd Then you will have my_type in foo.xsd customized while in bar.xsd you will have the original generated type. Moving --custom-type from foo.xsd to bar.xsd should also work. hth, -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/20070315/d33f661f/attachment.pgp From beddoes at intient.com Thu Mar 15 05:53:39 2007 From: beddoes at intient.com (Bradley Beddoes) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Customizing Types problem In-Reply-To: <20070315070842.GA10063@karelia> References: <45F87813.6000400@intient.com> <45F8C0BA.4030400@intient.com> <20070315070842.GA10063@karelia> Message-ID: <45F917A3.7060402@intient.com> Hi Boris and Ray, You will both have to forgive me I had tried this originally and it compiled both schema hence changing creating the dual custom types. I have just tried this again now and it works fine, obviously last night I was running a different command which I thought was this :(. I appreciate the help from both of you, thanks very much. regards, Bradley Boris Kolpackov wrote: > Hi Bradley, > > Bradley Beddoes writes: > >> Yes but in this instance one relies on components from the other so >> both must be supplied unfortunately. > > I think Ray's suggestion should work. If one relies on the other then > there must be an import statement. The --custom-type option only > affects the target namespace of the schema being compiled. For > example, if you have schema foo.xsd and bar.xsd. foo.xsd imports > bar.xsd. Both of them define say, my_type. If you do: > > $ xsd cxx-tree --custom-type my_type foo.xsd > $ xsd cxx-tree bar.xsd > > Then you will have my_type in foo.xsd customized while in bar.xsd > you will have the original generated type. Moving --custom-type > from foo.xsd to bar.xsd should also work. > > > hth, > -boris -- Bradley Beddoes Lead Software Architect http://intient.com Intient - "Open Source, Open Standards" From romain.garrigues at c-s.cnes.fr Thu Mar 15 12:08:09 2007 From: romain.garrigues at c-s.cnes.fr (Romain Garrigues) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Abstract objects problem References: <200703150955.l2F9t4Lp002091@codesynthesis.com> Message-ID: <200703151605.l2FG5NM22823@cnes.fr> Hello all, I'm a beginner in using this xsd library (parse version) I have a problem with abstract objects. This is my xsd file : I have defined an abstract concept (AbstractTransformationModelType), and two classes which are subclasses of this concept (AffineTransformationModelType and ProjectiveTransformationModelType). Then, CoordinatesTransformationModelType has an element which is that abstract concept. Then, i have defined parsers for each complexType. I don't understand how to define CoordinatesTransformationModel_parser in driver.cxx so i can parse different xml files. If i define it with AbstractTransformationModel_parser, i only have m_name of m_transformation. If i define it with AffineTransformationModel_parser, it will be ok if there is an affine transformation in xml file, but won't be ok if there is a projective transformation... I just want a polymorphic comportment in fact... The objective is to have the same code to parse different xml files, and i don't know how to do when there are abstract type. Best Regards. Romain Garrigues. From rlischner at proteus-technologies.com Thu Mar 15 12:16:37 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Minor issue: debug printing of byte and unsignedByte Message-ID: Overloading operator<<(ostream&, x) is a nice feature for quick debugging and dumping of data. The only problem arises with elements of type byte or unsignedByte.Naturally, Code Synthesis maps these to signed char and unsigned char, but the standard ostream class (incorrectly, in my opinion) prints these types as though they were characters, not integers. It would be better for Code Synthesis to insert a static_cast to int or unsigned int prior to streaming byte and unsignedByte values to basic_ostream. (Of course, custom stream insertion should leave the types alone, to let the stream class handle them correctly.) -- Ray Lischner, Proteus Technologies From rlischner at proteus-technologies.com Thu Mar 15 13:08:35 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] instance document parsing failed Message-ID: Most of the time, I use stream insertion & extraction, but we also need to support XML. I am now trying to get round-trip XML processing to work. I set up the namespace_infomap and write an XML file. Then I try to read that same file back in, but I get an xml_schema::parsing exception with no errors. Thus, all I get is a message, "instance document parsing failed" with no idea why. I even set up my own error handler; it is never called, but parsing fails nonetheless. When I introduce deliberate errors in the XML document, I get the expected error messages. When I create a simple program that uses a XercesDOMParser (calling doNamespaces(true) and doSchema(true)), it parses the document without any errors. Any hints on where to start looking for the problem? -- Ray Lischner, Proteus Technologies From rlischner at proteus-technologies.com Thu Mar 15 13:44:20 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] instance document parsing failed References: Message-ID: User error. Never mind. -- Ray Lischner, Proteus Technologies ________________________________ From: xsd-users-bounces@codesynthesis.com on behalf of Ray Lischner Sent: Thu 3/15/2007 1:08 PM To: xsd-users@codesynthesis.com Subject: [xsd-users] instance document parsing failed Most of the time, I use stream insertion & extraction, but we also need to support XML. I am now trying to get round-trip XML processing to work. I set up the namespace_infomap and write an XML file. Then I try to read that same file back in, but I get an xml_schema::parsing exception with no errors. Thus, all I get is a message, "instance document parsing failed" with no idea why. I even set up my own error handler; it is never called, but parsing fails nonetheless. When I introduce deliberate errors in the XML document, I get the expected error messages. When I create a simple program that uses a XercesDOMParser (calling doNamespaces(true) and doSchema(true)), it parses the document without any errors. Any hints on where to start looking for the problem? -- Ray Lischner, Proteus Technologies From hari at cse.fau.edu Thu Mar 15 14:30:23 2007 From: hari at cse.fau.edu (Hari Kalva) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] URI syntax for xsi:noNamespaceSchemaLocation In-Reply-To: <200703150955.l2F9t4Lm002091@codesynthesis.com> References: <200703150955.l2F9t4Lm002091@codesynthesis.com> Message-ID: <00ad01c76730$0421bec0$5a535b83@irm.ad.fau.edu> Hi, I have a question on URI syntax in xsi:noNamespaceSchemaLocation. The parser fails if the file url contains double '/' as in file:// The error message I get is: "Instance document parsing failed" The following gives the parsing error: ^^^ The parser works only when the file url has a single '/'. The following works: ^^ Thanks. -hari From boris at codesynthesis.com Thu Mar 15 15:20:45 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] URI syntax for xsi:noNamespaceSchemaLocation In-Reply-To: <00ad01c76730$0421bec0$5a535b83@irm.ad.fau.edu> References: <200703150955.l2F9t4Lm002091@codesynthesis.com> <00ad01c76730$0421bec0$5a535b83@irm.ad.fau.edu> Message-ID: <20070315192045.GA11334@karelia> Hi Hari, Hari Kalva writes: > The parser fails if the file url contains double '/' as in file:// > The error message I get is: "Instance document parsing failed" > The following gives the parsing error: > > xsi:noNamespaceSchemaLocation="file://C:/Soil/VidSchema/TestSchema.xsd"> > ^^^ > > The parser works only when the file url has a single '/'. The following > works: > > xsi:noNamespaceSchemaLocation="file:/C:/Soil/VidSchema/TestSchema.xsd"> This seems to be a quirk of Xerces-C++ on Windows. On GNU/Linux it only works with "file://". I will ask on the Xerces-C++ mailing list. hth, -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/20070315/2fd5f438/attachment.pgp From boris at codesynthesis.com Thu Mar 15 15:35:44 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Minor issue: debug printing of byte and unsignedByte In-Reply-To: References: Message-ID: <20070315193544.GB11334@karelia> Hi Ray, Ray Lischner writes: > Overloading operator<<(ostream&, x) is a nice feature for quick > debugging and dumping of data. The only problem arises with elements > of type byte or unsignedByte. Naturally, Code Synthesis maps these > to signed char and unsigned char, but the standard ostream class > (incorrectly, in my opinion) prints these types as though they > were characters, not integers. It would be better for Code > Synthesis to insert a static_cast to int or unsigned int prior > to streaming byte and unsignedByte values to basic_ostream. Yes, this is definitely a good idea. Unfortunately, the implementation is quite hairy since these two types are handled by predefined operators. As a result, we will need to add those casts in the generated code. I've added this to my TODO list. thanks, -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/20070315/68c78efc/attachment.pgp From boris at codesynthesis.com Thu Mar 15 15:43:36 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Abstract objects problem In-Reply-To: <200703151605.l2FG5NM22823@cnes.fr> References: <200703150955.l2F9t4Lp002091@codesynthesis.com> <200703151605.l2FG5NM22823@cnes.fr> Message-ID: <20070315194336.GC11334@karelia> Hi Romain, Romain Garrigues writes: > I have defined an abstract concept (AbstractTransformationModelType), > and two classes which are subclasses of this concept > (AffineTransformationModelType and ProjectiveTransformationModelType). > Then, CoordinatesTransformationModelType has an element which is that > abstract concept. > > Then, i have defined parsers for each complexType. I don't understand > how to define CoordinatesTransformationModel_parser in driver.cxx so > i can parse different xml files. This is normally handled with XML Schema polymorphism features (either substitution groups or xsi:type). The bad news is that polymorphism is not yet supported by the C++/Parser mapping. We hope to implement this in the next release. If there is any way for you to know what type of XML you are getting, then you can create two parsers, one for AffineTransformationModelType and the other for ProjectiveTransformationModelType. And then use one of them depending on the type of document. hth, -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/20070315/b8cad78f/attachment.pgp From boris at codesynthesis.com Fri Mar 16 03:08:44 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] URI syntax for xsi:noNamespaceSchemaLocation In-Reply-To: <20070315192045.GA11334@karelia> References: <200703150955.l2F9t4Lm002091@codesynthesis.com> <00ad01c76730$0421bec0$5a535b83@irm.ad.fau.edu> <20070315192045.GA11334@karelia> Message-ID: <20070316070844.GA13381@karelia> Hi Hari, Boris Kolpackov writes: > Hari Kalva writes: > > > > xsi:noNamespaceSchemaLocation="file://C:/Soil/VidSchema/TestSchema.xsd"> > > This seems to be a quirk of Xerces-C++ on Windows. On GNU/Linux > it only works with "file://". I will ask on the Xerces-C++ mailing > list. Apparently, the correct format is file:///C:\Soil\VidSchema\TestSchema.xsd as defined in RFC1738, Section 3.10[1]. I tested this URI and it works fine. [1] http://tools.ietf.org/html/rfc1738#section-3.10 hth, -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/20070316/d8cd0e5f/attachment.pgp From romain.garrigues at c-s.cnes.fr Fri Mar 16 04:29:03 2007 From: romain.garrigues at c-s.cnes.fr (Romain Garrigues) Date: Sun Oct 11 15:33:54 2009 Subject: [xsd-users] Problem with abstract objects Message-ID: <200703160827.l2G8RBW13651@cnes.fr> Hello all, I'm a beginner in using this xsd library (parse version) I have a problem with abstract objects. This is my xsd file : I have defined an abstract concept (AbstractTransformationModelType), and two classes which are subclasses of this concept (AffineTransformationModelType and ProjectiveTransformationModelType). Then, CoordinatesTransformationModelType has an element which is that abstract concept. Then, i have defined parsers for each complexType. I don't understand how to define CoordinatesTransformationModel_parser in driver.cxx so i can parse different xml files. If i define it with AbstractTransformationModel_parser, i only have m_name of m_transformation. If i define it with AffineTransformationModel_parser, it will be ok if there is an affine transformation in xml file, but won't be ok if there is a projective transformation... I just want a polymorphic comportment in fact... The objective is to have the same code to parse different xml files, and i don't know how to do when there are abstract type. Best Regards. Romain Garrigues. From fukasawa_mitsuo at nifty.com Fri Mar 9 09:42:28 2007 From: fukasawa_mitsuo at nifty.com (Fukasawa Mitsuo) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] generated large file Message-ID: <45F17254.60903@nifty.com> Hi, The large file is generated when "ccmxl" is traslated using xsd-2.3.1. http://www.w3.org/TR/ccxml/ccxml.xsd ------------------- [fukasawa@vmfc6 ccxml]$ xsd cxx-tree --morph-anonymous --generate-inline --root-element ccxml ccxml.xsd [fukasawa@vmfc6 ccxml]$ ls -l -rw-rw-r-- 1 fukasawa fukasawa 80986946 Mar 9 11:24 ccxml.cxx <== !? -rw-rw-r-- 1 fukasawa fukasawa 130498 Mar 9 11:24 ccxml.hxx -rw-rw-r-- 1 fukasawa fukasawa 87455 Mar 9 11:24 ccxml.ixx -------------------- IMO, if default value is attached to attribute, an exessive idents is generated. The following is result to delete all "default" value. -------------------- -rw-rw-r-- 1 fukasawa fukasawa 148253 Mar 9 11:25 ccxml.cxx <== !! -rw-rw-r-- 1 fukasawa fukasawa 131119 Mar 9 11:25 ccxml.hxx -rw-rw-r-- 1 fukasawa fukasawa 87422 Mar 9 11:25 ccxml.ixx -rw-rw-r-- 1 fukasawa fukasawa 19757 Mar 9 11:14 ccxml.xsd -rw-rw-r-- 1 fukasawa fukasawa 5829 Feb 28 16:04 xml.xsd -------------------- regards, Mitsuo From paolo.volpi at tvblob.com Mon Mar 19 10:56:54 2007 From: paolo.volpi at tvblob.com (paolo.volpi@tvblob.com) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] grammar pool caching Message-ID: <23191FF44E6346449EE21BD590910997.MAI@auteri.net> Hi, is it possible to enable something like xercesc grammar pool caching with cxx-tree generated class to speed up the validation process? From boris at codesynthesis.com Mon Mar 19 11:08:22 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] grammar pool caching In-Reply-To: <23191FF44E6346449EE21BD590910997.MAI@auteri.net> References: <23191FF44E6346449EE21BD590910997.MAI@auteri.net> Message-ID: <20070319150822.GA32414@karelia> Hi, paolo.volpi@tvblob.com writes: > is it possible to enable something like xercesc grammar pool caching > with cxx-tree generated class to speed up the validation process? Yes it is. For that you will need to do XML-to-DOM parsing yourself where you can enable the grammar caching. One of the generated parsing functions accepts DOMDocument as input which you can then use to create the tree. The Wiki FAQ 2.1 has some code that does the XML-DOM stage: http://wiki.codesynthesis.com/Tree/FAQ The following article describes how to enable grammar caching: http://www-128.ibm.com/developerworks/webservices/library/x-xsdxerc.html hth, -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/20070319/f9181224/attachment.pgp From rlischner at proteus-technologies.com Mon Mar 19 13:18:51 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] --include-prefix logic Message-ID: I want to organize my #include headers as follows: xml/XmlSchema.h (for my --generate-xml-schema result) foo/Foo.h (for the Foo.xsd schema) In other words, I want Foo.h to contain the following directives: #include ... #include Similarly for Foo.cpp, which I want to #include and . But I can't figure out how to do that. If I use --include-prefix, the same prefix is used for XmlSchema.h and for Foo.txx. If I specify --extern-xml-schema xml/XmlSchema.xsd on the xsd command line, I get the right directive for XmlSchema.h, but I get for the template header. Right now, the only solution I can think of is to post-process the generated header with a Perl script. Is there a way I can arrange the headers the way I want using only Code Synthesis command line options? -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Mon Mar 19 13:27:32 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] --include-prefix logic In-Reply-To: References: Message-ID: <20070319172732.GD32414@karelia> Hi Ray, Ray Lischner writes: > I want to organize my #include headers as follows: > > xml/XmlSchema.h (for my --generate-xml-schema result) > foo/Foo.h (for the Foo.xsd schema) > > In other words, I want Foo.h to contain the following directives: > #include > ... > #include > > ... > > Is there a way I can arrange the headers the way I want using only > Code Synthesis command line options? There is the --include-regex option which allows you to mangle include directives in pretty much any way you want. One way to handle your case would be to use the following options: --extern-xml-schema XmlSchema.xsd --include-prefix foo/ --include-regex '%foo/XmlSchema\.(.+)%xml/XmlSchema.$1%' hth, -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/20070319/e24a4a7a/attachment.pgp From boris at codesynthesis.com Mon Mar 19 15:40:13 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] generated large file In-Reply-To: <45F17254.60903@nifty.com> References: <45F17254.60903@nifty.com> Message-ID: <20070319194013.GF32414@karelia> Hi, Sorry for the delay - your email was mistakenly caught by our spam filter it. Fukasawa Mitsuo writes: > The large file is generated when "ccmxl" is traslated using xsd-2.3.1. > http://www.w3.org/TR/ccxml/ccxml.xsd There was a bug in indenter which I have fixed. With a small fix to the typo in the schema: Boolean: true or false only I was able to compile the generated code without any problems. The fix will appear in the next release. If you want, I can build you a pre- release for the meantime. Just let me know which OS/CPU you are using. Thanks for reporting this! -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/20070319/720798f7/attachment.pgp From boris at codesynthesis.com Tue Mar 20 06:46:24 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] XSD/e 1.0.0 released Message-ID: <20070320104624.GF9706@karelia> Hi, We are pleased to announce the release of CodeSynthesis XSD/e 1.0.0. XSD/e is an XML parser generator for mobile and embedded systems. Similar to XSD, it provides event-driven, stream-oriented XML parsing, XML Schema validation, and C++ data binding while maintaining small footprint and portability. Compared to general-purpose validating XML parsers, the XSD/e-generated parsers are 2-10 times faster while maintaining the lowest static and dynamic memory footprints. For example, a validating parser executable can be as small as 120KB in size. XSD/e is also highly-portable and can be used without STL, RTTI, iostream, C++ exceptions, and C++ templates. Supported embedded toolchains include GNU g++ 2.95.x-4.x.x, eMbedded Visual C++ 4.0, and Visual Studio 2005 with Smart Devices support. Precompiled binary distributions are available for GNU/Linux, Solaris, and Windows host development platforms. More information, documentation, source code, and precompiled binaries are available from http://www.codesynthesis.com/products/xsde/ 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/20070320/4e84e280/attachment.pgp From boris at codesynthesis.com Tue Mar 20 09:45:28 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] grammar pool caching In-Reply-To: <200703201434.11722.paolo.volpi@tvblob.com> References: <23191FF44E6346449EE21BD590910997.MAI@auteri.net> <20070319150822.GA32414@karelia> <200703201434.11722.paolo.volpi@tvblob.com> Message-ID: <20070320134528.GE10640@karelia> Hi Paolo, In the future please keep the xsd-users mailing list CC'ed to your replies. This way others will be able to benefit from this information. Paolo Volpi writes: > Is it not usefull/possible to offer this capability directly from > your library for example with a flags? This particular feature is probably not possible because the parsing functions create a new DOM parser every time they are called so there won't be any caching. Generally, we only duplicate most essential Xerces-C++ flags and properties (like dont_validate, etc.). The idea is that if you need to do something special then you will need to create the DOMDocument yourself. The good thing about this approach is that it is very flexible and allows us to concentrate on the core features instead of duplicating Xerces-C++ interfaces. hth, -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/20070320/00c10baf/attachment.pgp From boris at codesynthesis.com Tue Mar 20 11:28:43 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Re: Some questions about xsd In-Reply-To: <955700766.20070320153956@mail.ru> References: <955700766.20070320153956@mail.ru> Message-ID: <20070320152843.GF10640@karelia> Hi Sergei, In the future please send technical questions like this to the xsd-users mailing list (which I've CC'ed) rather than to me directly. This way a) other developers who may have experienced a similar problem can provide you with a solution and b) questions and answers will be archived and available to others with similar problems. Sergei V. Firsov writes: > At first, i want to say BIG THANKS for your product XSD. > It's first product which is really can parse/serialize xsd/xml > schemas and files and sources really works. This is nice of you to say, thanks! I am glad you're enjoying it. > But i have some questions: > - Is it possible to include xsi:type attribute into ouptut file? > Something like this: > > > I have found type-serializer-map files, but how use it? At the moment XSD includes xsi:type only when the actual type and the declared type differ. This is a common practice and results in XML instances which are not bloated with unnecessary xsi:type attributes. Why would you need to include xsi:type in places where it is not required? > - For example my XSD schema is: > <xs:complexType name="ItemContentType" abstract="true"> > <xs:sequence> > <xs:element name="Label" type="xs:normalizedString" nillable="true" minOccurs="0"/> > <xs:element name="is_a" type="RecordIdType" nillable="true" minOccurs="0" maxOccurs="unbounded"/> > </xs:sequence> > <xs:attribute name="isClosed" type="xs:boolean" use="optional" default="false"/> > <xs:attribute name="isWeaklySigned" type="xs:boolean" use="optional" default="false"/> > <xs:attribute name="isWeaklyEncrypted" type="xs:boolean" use="optional" default="false"/> > </xs:complexType> > > How i can force xsd include "isClose", isWeaklySigned and etc > only if attribute value not equal default value? We are planning to implement this in the next version. I will let you know when there is a beta for you to try. > > Now i have solved this problem by modifing "<<" output operator > ---------- > if (i.isWeaklySigned() != pimessage::ItemContentType::isWeaklySigned::default_value()) > { > ::xsd::cxx::xml::dom::attribute< wchar_t > a ( > L"isWeaklySigned", > e); > a.dom_attribute () << i.isWeaklySigned (); > } > ---------- > But i think it's not good solution, in't it? That's pretty much what we will have in the generated code so you can use this method for now. Its major drawback is that your changes will be lost when you regenerate your code. Thanks for the suggestions! -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/20070320/756c5efb/attachment.pgp From rlischner at proteus-technologies.com Tue Mar 20 16:10:19 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] generic framework vs. XML functions Message-ID: <F1886AFB628EA94098943970F1563B89CA5506@LINUS.proteus-technologies.com> We are writing a framework that processes objects of many different Code Synthesis-generated types. We'd like to be able to write a single function that can serialize any such object to XML. One of the hurdles is that the name and namespace of the root element are encoded as strings hardcoded into functions. I see no way to write normal C++ code to extract that information. The framework, therefore, requires the caller to supply the root element name and namespace as arguments, which is error-prone and redundant. Is there any other way to deal with this problem? -- Ray Lischner, Proteus Technologies From paolo.volpi at tvblob.com Wed Mar 21 05:31:11 2007 From: paolo.volpi at tvblob.com (Paolo Volpi) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Question about a possible bug on DomDatatypeNormalization feature Message-ID: <200703211031.11644.paolo.volpi@tvblob.com> In xsd-2.3.1/libxsd/xsd/cxx/xml/dom/elements.txx line 480 : // Disable datatype normalization. The XML 1.0 attribute value // normalization always occurs though. // parser->setFeature (XMLUni::fgDOMDatatypeNormalization, true); Is it correct to set that feature to true? Isn't to set to false for disabling the normalization as the comment said? From bdewacht at gmail.com Wed Mar 21 06:41:57 2007 From: bdewacht at gmail.com (Bram De Wachter) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Bug with groups and occurence Message-ID: <a875fa930703210341m4deaf87q9da62495b9c6925@mail.gmail.com> I have the following XSD, which describes general expressions (binary/unary operators and constant operands) <xs:element name="Expression" type="ExpressionType"/> Where an Expression is: <xs:complexType name="ExpressionType"> <xs:group ref="ExpressionGroup"> ... </xs:complexType> Expressions are either binary or unary operators or constants: <xs:group name="ExpressionGroup"> <xs:choice> <xs:group ref="BinaryOperatorsGroup"/> <xs:group ref="UnaryOperatorsGroup"/> <xs:element name="Constant" type="xs:int"/> ... </xs:choice> </xs:group> BinaryOperators can be Div, Add ... <xs:group name="BinaryOperatorsGroup"> <xs:choice> <xs:element name="Div" type="BinaryOperatorType"/> <xs:element name="Add" type="BinaryOperatorType"/> </xs:choice> </xs:group> While a Binary operator takes exactly two Expressions <xs:complexType name="BinaryOperatorType"> <xs:group ref="ExpressionGroup" minOccurs="2" maxOccurs="2"/> </xs:complexType> Et voil?, XSD tree 2.3.1 generates the BinaryOperatorType class with only (!!!) containers (!!!) for all possible operators (unary/binary). So it is impossible to find out the sequence in which the operands appear. Example: <Expression> <Div> <Constant>5</Constant> <Sum> <Constant>2</Constant> <Constant>1</Constant> </Sum> </Div> </Expression> 1/ There is no way to find out if the sum comes before the Constant 5 or the other way around. 2/ Also, it is not clear to me how both Constants (1 and 2) are inserted in a single container. Regards, Bram De Wachter. From boris at codesynthesis.com Wed Mar 21 08:59:40 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Question about a possible bug on DomDatatypeNormalization feature In-Reply-To: <200703211031.11644.paolo.volpi@tvblob.com> References: <200703211031.11644.paolo.volpi@tvblob.com> Message-ID: <20070321125940.GA13626@karelia> Hi Paolo, Paolo Volpi <paolo.volpi@tvblob.com> writes: > In xsd-2.3.1/libxsd/xsd/cxx/xml/dom/elements.txx line 480 : > > // Disable datatype normalization. The XML 1.0 attribute value > // normalization always occurs though. > // > parser->setFeature (XMLUni::fgDOMDatatypeNormalization, true); > > Is it correct to set that feature to true? Isn't to set to false > for disabling the normalization as the comment said? We actually want this feature on, so it is the comment that is wrong. There is a similar chunk of code around line 354 that reads like this: // Enable datatype normalization. // parser->setFeature (XMLUni::fgDOMDatatypeNormalization, true); I've fixed the comment. Thanks for reporting this! -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/20070321/e655245b/attachment.pgp From boris at codesynthesis.com Wed Mar 21 09:34:22 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Bug with groups and occurence In-Reply-To: <a875fa930703210341m4deaf87q9da62495b9c6925@mail.gmail.com> References: <a875fa930703210341m4deaf87q9da62495b9c6925@mail.gmail.com> Message-ID: <20070321133422.GC13626@karelia> Hi Bram, Bram De Wachter <bdewacht@gmail.com> writes: > Et voil?, XSD tree 2.3.1 generates the BinaryOperatorType class with > only (!!!) containers (!!!) for all possible operators (unary/binary). > So it is impossible to find out the sequence in which the operands > appear. > > Example: > > <Expression> > <Div> > <Constant>5</Constant> > <Sum> > <Constant>2</Constant> > <Constant>1</Constant> > </Sum> > </Div> > </Expression> > > 1/ There is no way to find out if the sum comes before the Constant 5 > or the other way around. We made a choice to go with a flattened structure, one side-effect of which is the loss of ordering information in some cases. You can read more about this trade-off in the recent thread titled "<choice> abuse", particularly this post: http://codesynthesis.com/pipermail/xsd-users/2007-March/000863.html To be able to preserve ordering information, we would have to resort to a single sequence that contains all sub-elements. Since such a container would need to store elements of different types, it would need to store a pointer to some base type which you would have to dynamic_cast to figure out what each element actually is (.e.g., is it a Constant, or a Sum, or a Div?). I think by now you realize that such a structure would look a lot like DOM. One way to work around this problem would be to use the DOM association feature. It allows you to keep an association between DOM nodes and Tree nodes and to get from Tree node to a DOM and back. So, in your case, you would handle the above example like this: 1. Get to the Div Tree node 2. Get a DOMElement instance corresponding to Div 3. Iterate over Div DOMElement's sub-elements in the order of appearance. 4. From each sub-element DOMElement get back to the Tree node (Constant and Sum in the example above). For more information on this feature see the 'mixed' example as well as the C++/Tree mapping manual. Alternatively, if you can change your XML, then you could establish explicit ordering, for example: <Div> <Arg> <Constant>5</Constant> </Arg> <Arg> <Sum> <Arg> <Constant>2</Constant> </Arg> <Arg> <Constant>1</Constant> </Arg> </Sum> </Arg> </Div> > 2/ Also, it is not clear to me how both Constants (1 and 2) are > inserted in a single container. They are inserted in the order of appearance in the XML instance. hth, -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/20070321/c03fb2ea/attachment.pgp From boris at codesynthesis.com Wed Mar 21 10:26:51 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] generic framework vs. XML functions In-Reply-To: <F1886AFB628EA94098943970F1563B89CA5506@LINUS.proteus-technologies.com> References: <F1886AFB628EA94098943970F1563B89CA5506@LINUS.proteus-technologies.com> Message-ID: <20070321142651.GD13626@karelia> Hi Ray, Ray Lischner <rlischner@proteus-technologies.com> writes: > We are writing a framework that processes objects of many different > Code Synthesis-generated types. We'd like to be able to write a > single function that can serialize any such object to XML. One of > the hurdles is that the name and namespace of the root element are > encoded as strings hardcoded into functions. I see no way to write > normal C++ code to extract that information. The framework, therefore, > requires the caller to supply the root element name and namespace as > arguments, which is error-prone and redundant. > > Is there any other way to deal with this problem? This problem is conceptually difficult to solve because your objects are of some XML Schema types and XML Schema types can be used for several elements, e.g., <complexType name="Foo"> ... </complexType> <element name="foo" type="Foo"/> <element name="bar" type="Foo"/> As a result it would be wrong to associate an element name with a type. In your case case it is probably one-to-one relationship but in general it is not so. I don't see any clean way to solve this in an automatic way. Another alternative to the manual method you suggested (passing element name to the function) would be to have some kind of a global map which is manually populated and maps typeids to element names. This is a pain to maintain though. Or you could write a custom code generator that would generate this map automatically... hth, -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/20070321/cccfc59f/attachment.pgp From rlischner at proteus-technologies.com Wed Mar 21 15:59:07 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] generic framework vs. XML functions References: <F1886AFB628EA94098943970F1563B89CA5506@LINUS.proteus-technologies.com> <20070321142651.GD13626@karelia> Message-ID: <F1886AFB628EA94098943970F1563B89CA5508@LINUS.proteus-technologies.com> One solution is to generate a class for each root element instead of or in addition to the global functions. The class would have members to provide the root element name and namespace. The functor class could have overloaded operators for all the currently global functions. Automatically define an instance of the class with the element name, and you would have a solution that is nearly source-level compatible with existing code, and provides the necessary information for anyone who needs the element name and namespace programmatically. Just a suggestion. -- Ray Lischner, Proteus Technologies ________________________________ From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wed 3/21/2007 10:26 AM To: Ray Lischner Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] generic framework vs. XML functions Hi Ray, Ray Lischner <rlischner@proteus-technologies.com> writes: > We are writing a framework that processes objects of many different > Code Synthesis-generated types. We'd like to be able to write a > single function that can serialize any such object to XML. One of > the hurdles is that the name and namespace of the root element are > encoded as strings hardcoded into functions. I see no way to write > normal C++ code to extract that information. The framework, therefore, > requires the caller to supply the root element name and namespace as > arguments, which is error-prone and redundant. > > Is there any other way to deal with this problem? This problem is conceptually difficult to solve because your objects are of some XML Schema types and XML Schema types can be used for several elements, e.g., <complexType name="Foo"> ... </complexType> <element name="foo" type="Foo"/> <element name="bar" type="Foo"/> As a result it would be wrong to associate an element name with a type. In your case case it is probably one-to-one relationship but in general it is not so. I don't see any clean way to solve this in an automatic way. Another alternative to the manual method you suggested (passing element name to the function) would be to have some kind of a global map which is manually populated and maps typeids to element names. This is a pain to maintain though. Or you could write a custom code generator that would generate this map automatically... hth, -boris From boris at codesynthesis.com Thu Mar 22 14:23:06 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] generic framework vs. XML functions In-Reply-To: <F1886AFB628EA94098943970F1563B89CA5508@LINUS.proteus-technologies.com> References: <F1886AFB628EA94098943970F1563B89CA5506@LINUS.proteus-technologies.com> <20070321142651.GD13626@karelia> <F1886AFB628EA94098943970F1563B89CA5508@LINUS.proteus-technologies.com> Message-ID: <20070322182306.GB17725@karelia> Hi Ray, Ray Lischner <rlischner@proteus-technologies.com> writes: > One solution is to generate a class for each root element instead > of or in addition to the global functions. The class would have > members to provide the root element name and namespace. I don't see how this will help you. I thought you wanted your function to take an object of some generated type and automatically figure out what element name and namespace to serialize it with. With this approach, the user will still need to pass the element name and namespace explicitly. The only advantage of this approach is that the user does not have to spell the name and namespace explicitly (which is an improvement but still no cigar). > The functor class could have overloaded operators for all the > currently global functions. Automatically define an instance of > the class with the element name, and you would have a solution > that is nearly source-level compatible with existing code, and > provides the necessary information for anyone who needs the > element name and namespace programmatically. This is clever but won't be necessary - in the next version (3.0.0), we are going to break backwards compatibility anyway so if something is a clear improvement we can do it in a straightforward way. thanks, -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/20070322/1e57ecdf/attachment.pgp From rlischner at proteus-technologies.com Fri Mar 23 12:30:46 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Help me understand XML parsing code Message-ID: <F1886AFB628EA94098943970F1563B89CA550C@LINUS.proteus-technologies.com> I'm trying to understand the code that Code Synthesis generates to parse XML. It seems that the code checks for element names and ensures that the namespace is empty. I don't understand the last part. I'm trying to make sure I use correct XML, and if the schema has a targetNamespace, shouldn't the instance use that namespace? And shouldn't the generated code check for that namespace? What am I missing? -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Fri Mar 23 13:07:57 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Help me understand XML parsing code In-Reply-To: <F1886AFB628EA94098943970F1563B89CA550C@LINUS.proteus-technologies.com> References: <F1886AFB628EA94098943970F1563B89CA550C@LINUS.proteus-technologies.com> Message-ID: <20070323170757.GA20532@karelia> Hi Ray, Ray Lischner <rlischner@proteus-technologies.com> writes: > It seems that the code checks for element names and ensures that > the namespace is empty. I don't understand the last part. I'm > trying to make sure I use correct XML, and if the schema has a > targetNamespace, shouldn't the instance use that namespace? And > shouldn't the generated code check for that namespace? I can't say for sure without seeing the schema but I suspect you are talking about unqualified local elements in a schema with target namespace, e.g.: <schema targetNamespace="test" xmlns:t="test" xmlns="http://www.w3.org/2001/XMLSchema"> <complexType name="type"> <sequence> <element name="foo" type="string"/> </sequence> </complexType> <element name="bar" type="t:type"/> </schema> In the schema above, element 'bar' is in the 'test' namespace while local element 'foo' is not in any namespace (which is in the XSD- generated code is indicated by an empty string). If you want local elements like 'foo' to also be qualified, then you will need to add elementFormDefault="qualified" to the schema declaration: <schema targetNamespace="test" xmlns:t="test" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> ... </schema> hth, -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/20070323/b8ae1bcd/attachment.pgp From sergey at hyperroll.com Wed Mar 28 06:03:51 2007 From: sergey at hyperroll.com (Sergey Tatarenko) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Extended validation in generated c++ code Message-ID: <6cf014660703280303p53d033dcn893e8cfd12c2be80@mail.gmail.com> Hi, Is there a way to extend the default validation in generated classes? I couldn't find any reference to this in documentation. Thanks in advance, Sergey Tatarenko. From boris at codesynthesis.com Wed Mar 28 06:48:33 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Extended validation in generated c++ code In-Reply-To: <6cf014660703280303p53d033dcn893e8cfd12c2be80@mail.gmail.com> References: <6cf014660703280303p53d033dcn893e8cfd12c2be80@mail.gmail.com> Message-ID: <20070328104833.GA13706@karelia> Hi Sergey, Sergey Tatarenko <sergey@hyperroll.com> writes: > Is there a way to extend the default validation in generated classes? I don't understand the questions. Could you please describe what you are trying to achieve in a bit more detail. A concrete example might also help. thanks, -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/20070328/0e0240a7/attachment.pgp From mark.kinzie at jhuapl.edu Wed Mar 28 09:30:47 2007 From: mark.kinzie at jhuapl.edu (Mark Kinzie) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Compiler warnings in VS 2005 Message-ID: <460A6E07.8000001@jhuapl.edu> Hi, I'm working with the latest XSD using cxx-tree in Visual Studio 2005. I've set up to use xsd according to the README. I manually run xsd, and then copy the resulting .cxx and .hxx files to a directory in my project, and everything works, except that I get the following compiler warnings. Is there any way to get rid of them? xsd/cxx/tree/exceptions.hxx(102) : warning C4224: nonstandard extension used : formal parameter 'errors' was previously defined as a type xsd/cxx/tree/exceptions.hxx(119) : see reference to class template instantiation 'xsd::cxx::tree::parsing<C>' being compiled xsd/cxx/tree/exceptions.hxx(421) : warning C4224: nonstandard extension used : formal parameter 'errors' was previously defined as a type xsd/cxx/tree/exceptions.hxx(438) : see reference to class template instantiation 'xsd::cxx::tree::serialization<C>' being compiled xsd/cxx/tree/exceptions.hxx(102) : warning C4224: nonstandard extension used : formal parameter 'errors' was previously defined as a type xsd/cxx/tree/exceptions.ixx(54) : see reference to class template instantiation 'xsd::cxx::tree::parsing<C>' being compiled with [ C=char ] xsd/cxx/tree/exceptions.hxx(421) : warning C4224: nonstandard extension used : formal parameter 'errors' was previously defined as a type xsd/cxx/tree/exceptions.ixx(186) : see reference to class template instantiation 'xsd::cxx::tree::serialization<C>' being compiled with [ C=char ] xsd/cxx/tree/types.hxx(1204) : warning C4224: nonstandard extension used : formal parameter 'name' was previously defined as a type xsd/cxx/tree/types.hxx(1261) : see reference to class template instantiation 'xsd::cxx::tree::qname<C,B,uri,ncname>' being compiled Thanks, Mark From boris at codesynthesis.com Wed Mar 28 12:13:37 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Extended validation in generated c++ code In-Reply-To: <6cf014660703280653l5c2f28a4y2d949b94fdfa912c@mail.gmail.com> References: <6cf014660703280303p53d033dcn893e8cfd12c2be80@mail.gmail.com> <20070328104833.GA13706@karelia> <6cf014660703280653l5c2f28a4y2d949b94fdfa912c@mail.gmail.com> Message-ID: <20070328161337.GA14663@karelia> Hi Sergey, In the future please keep the xsd-users mailing list CC'ed to your replies. This way a) other developers who may have experienced a similar problem can provide you with a solution and b) questions and answers will be archived and available to others with similar problems. Sergey Tatarenko <sergey@hyperroll.com> writes: > I want to add certain checks/validations which I can't do with xsd schema > language. I see now, thanks for clarifying this. There are two ways to achieve this that I can think of. First is to simply write external code that will perform the additional checks after the XML instance have been parsed but before the resulting tree is used for further processing. You could, for example, wrap the parsing function with your own code and instruct the users to call it to obtain the tree. A more elaborate approach would be to customize some of the generated classes with the code that performs the additional validation. You could, for example, customize the parsing constructors and add your own logic after calling the standard parsing code. For more information on how to customize the generated code, please see the C++/Tree Mapping Customization Guide: http://wiki.codesynthesis.com/Tree/Customization_guide There is also the wildcard example in the examples/cxx/tree/custom directory that shows how to customize the parsing c-tor. hth, -boris [The rest of the original email follows for context.] > Here 2 major problems that I did'f find a way to eliminate by xsd schema > rules: > > a) There is a type that have reference to items of the same type, and I want > to check that a n object of that type is not referencing to itself. Or even > more, there should not be cyclic references A->B->C->A > > b) Another problem is to check that if there is such a reference A->B, A has > a reference to B. In a sequence that holds those objects B must appear > before A -------------- 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/20070328/881d7033/attachment.pgp From boris at codesynthesis.com Wed Mar 28 12:32:51 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Compiler warnings in VS 2005 In-Reply-To: <460A6E07.8000001@jhuapl.edu> References: <460A6E07.8000001@jhuapl.edu> Message-ID: <20070328163251.GB14663@karelia> Hi Mark, Mark Kinzie <mark.kinzie@jhuapl.edu> writes: > I'm working with the latest XSD using cxx-tree in Visual Studio 2005. > I've set up to use xsd according to the README. I manually run xsd, and > then copy the resulting .cxx and .hxx files to a directory in my > project, and everything works, except that I get the following compiler > warnings. Is there any way to get rid of them? > > xsd/cxx/tree/exceptions.hxx(102) : warning C4224: nonstandard extension I was surprised we didn't see these warnings. After some digging it appear that this warning (C4224) is only issued when compiled with the /Za option (ANSI compatibility). The way to get rid of it is to add the following line to libxsd/xsd/cxx/compilers/vc-8/pre.hxx: #pragma warning (disable:4224) It will disable this warning for the XSD-generated code and the runtime. This fix will also appear in the next release of XSD. Thanks for reporting this! -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/20070328/579d67d6/attachment.pgp From mark.kinzie at jhuapl.edu Wed Mar 28 12:55:38 2007 From: mark.kinzie at jhuapl.edu (Mark Kinzie) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Compiler warnings in VS 2005 In-Reply-To: <20070328163251.GB14663@karelia> References: <460A6E07.8000001@jhuapl.edu> <20070328163251.GB14663@karelia> Message-ID: <460A9E0A.5080605@jhuapl.edu> Thanks Boris! It's nice to have that fixed. Mark Boris Kolpackov wrote: > Hi Mark, > > Mark Kinzie <mark.kinzie@jhuapl.edu> writes: > > >> I'm working with the latest XSD using cxx-tree in Visual Studio 2005. >> I've set up to use xsd according to the README. I manually run xsd, and >> then copy the resulting .cxx and .hxx files to a directory in my >> project, and everything works, except that I get the following compiler >> warnings. Is there any way to get rid of them? >> >> xsd/cxx/tree/exceptions.hxx(102) : warning C4224: nonstandard extension >> > > I was surprised we didn't see these warnings. After some digging it > appear that this warning (C4224) is only issued when compiled with > the /Za option (ANSI compatibility). The way to get rid of it is to > add the following line to libxsd/xsd/cxx/compilers/vc-8/pre.hxx: > > #pragma warning (disable:4224) > > It will disable this warning for the XSD-generated code and the runtime. > This fix will also appear in the next release of XSD. > > > Thanks for reporting this! > > > -boris > From Robert.Greger at GeneralDigital.com Thu Mar 29 04:00:54 2007 From: Robert.Greger at GeneralDigital.com (Robert Greger) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] XSD Platform Support-ARM7 and SH82215 Message-ID: <460B7236.4020404@GeneralDigital.com> What would be involved in porting the code to ARM7 (RealView toolset) and the SH82215 (HEW Toolset)? -- Robert Greger Software Engineering Services General Digital Corporation 860-282-2900 ext. 142 http://www.GeneralDigital.com From boris at codesynthesis.com Thu Mar 29 04:09:16 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] XSD Platform Support-ARM7 and SH82215 In-Reply-To: <460B7236.4020404@GeneralDigital.com> References: <460B7236.4020404@GeneralDigital.com> Message-ID: <20070329080916.GB20586@karelia> Hi Robert, Robert Greger <Robert.Greger@GeneralDigital.com> writes: > What would be involved in porting the code to ARM7 (RealView toolset) > and the SH82215 (HEW Toolset)? This might require a substantial effort, depending on how conformant the C++ compilers in these toolsets are. While XSD is used in embedded systems (usually the beefier ones), it is primarily targeted at non- embedded development. XSD/e, on the other hand, is specifically designed for embedded systems and will most likely work out of the box with these toolsets, at least in its minimal configuration: http://www.codesynthesis.com/products/xsde/ We can also provide porting assistance if there are any problems. hth, -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/20070329/9a0ff72d/attachment.pgp From rlischner at proteus-technologies.com Thu Mar 29 09:05:55 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] New idea for stream insertion & extraction Message-ID: <F1886AFB628EA94098943970F1563B89CA5512@LINUS.proteus-technologies.com> One of the key distinguishing features that sets Code Synthesis off from other XML data binding tools is stream insertion and extraction. I can write a stream class to support formats other than XML. One thing missing from the current system, however, is any notion of structure. Having low-level data without structure is fine for CDR, but doesn't work as well for, say, ASN.1 DER. Here's an idea I recently had for how to add structure to stream insertion & extraction. This scheme is low-cost, but affects the code generator. Simply, add a requirement that the stream insertion and extraction classes have member functions: start(char const*) and end(char const*). The code generator generates suitable calls to these functions. After that, it's entirely up the stream class to deal with that information. The ACE CDR stream classes would implement them as inline empty functions, so there would be nearly no cost. An ASN.1 DER class would use the start and end functions to generate structure tags. In other words, if the schema has something like this: <complexType name="point"> <sequence> <element name="x" type="int"/> <element name="y" type="int"/> </sequence> </complexType> <element name="origin" type="point"/> The code generator would generate stream insertion operators like this: template<class S> xsd::cxx::tree::ostream<S> operator<<(xsd::cxx::tree::ostream<S>& s, point const& x) { start("x"); s << x(); end("x"); start("y"); s << y(); end("y"); } Code Synthesis would need to add global functions for the root elements: template<class S> void origin(xsd::cxx::tree::ostream<S>& s, point const& x) { s.start("origin"); s << x; s.end("origin"); } Stream extraction is a little harder. The stream extraction constructor could take another argument for the element name (here is the unavoidable cost, even if the steam classes ignore the name and structure, passing the name argument imposes a small cost): point::point(xsd::cxx::tree::istream<S>& s, xml_schema::flags f, xml_schema::type* c, char const* name) : xml_schema::type(s, f, c, name), _xsd_x_(s, f, this, "x"), _xsd_y_(s, f, this, "y") { s.end(name); } The type::type constructor calls s.start(name) in its body, and other classes would call end(). For example the fundamental_base constructor might be: fundamental_base::fundamental_base(...) { X& r(*this); s >> r; s.end(name); } Thus, the calls to start() and end() preserve the structure, even if the code is slightly harder to read and understand than the stream insertion case. -- Ray Lischner, Proteus Technologies From mur at freenet.am Thu Mar 29 04:29:14 2007 From: mur at freenet.am (Arthur) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Is there a way to compile XSD annotations into comments? Message-ID: <200703290829.l2T8TE9r000701@anubis.freenet.am> Hi, does XSD have option(or something like that) which will put XSD annotations to comments in generated C++ code. Thanks in advance, Arthur From boris at codesynthesis.com Thu Mar 29 09:07:23 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Is there a way to compile XSD annotations into comments? In-Reply-To: <200703290829.l2T8TE9r000701@anubis.freenet.am> References: <200703290829.l2T8TE9r000701@anubis.freenet.am> Message-ID: <20070329130723.GC22226@karelia> Hi Arthur, Arthur <mur@freenet.am> writes: > does XSD have option(or something like that) which will put XSD > annotations to comments in generated C++ code. No, not yet. Ray Lischner suggested that we generate a Doxygen- formatted comments with annotations from the schema as descriptions. Would you also prefer a Doxygen format or just plain text? thanks, -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/20070329/1b7d51c8/attachment.pgp From efdegroot at corp.csnet.nl Thu Mar 29 09:31:19 2007 From: efdegroot at corp.csnet.nl (Eelko de Groot) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Is there a way to compile XSD annotations into comments? In-Reply-To: <20070329130723.GC22226@karelia> References: <200703290829.l2T8TE9r000701@anubis.freenet.am> <20070329130723.GC22226@karelia> Message-ID: <460BBFA7.2070504@corp.csnet.nl> Hi Boris, If I may, I definitely would prefer the Doxygen format. Regards. Eelko de Groot Boris Kolpackov schreef: > Hi Arthur, > > Arthur <mur@freenet.am> writes: > > >> does XSD have option(or something like that) which will put XSD >> annotations to comments in generated C++ code. >> > > No, not yet. Ray Lischner suggested that we generate a Doxygen- > formatted comments with annotations from the schema as descriptions. > Would you also prefer a Doxygen format or just plain text? > > thanks, > -boris > From tmaenner at aehr.com Thu Mar 29 13:23:37 2007 From: tmaenner at aehr.com (Thomas Maenner) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Is there a way to compile XSD annotations into comments? In-Reply-To: <20070329130723.GC22226@karelia> References: <200703290829.l2T8TE9r000701@anubis.freenet.am> <20070329130723.GC22226@karelia> Message-ID: <200703291023.37354.tmaenner@aehr.com> Hi Boris, Rather than which we would prefer, how about and / or? Thanks, Tom On Thursday 29 March 2007 06:07, Boris Kolpackov wrote: > Hi Arthur, > > Arthur <mur@freenet.am> writes: > > does XSD have option(or something like that) which will put XSD > > annotations to comments in generated C++ code. > > No, not yet. Ray Lischner suggested that we generate a Doxygen- > formatted comments with annotations from the schema as descriptions. > Would you also prefer a Doxygen format or just plain text? > > thanks, > -boris -- Thomas Maenner E-Mail: mailto:tmaenner@aehr.com From boris at codesynthesis.com Thu Mar 29 17:30:47 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Is there a way to compile XSD annotations into comments? In-Reply-To: <200703291023.37354.tmaenner@aehr.com> References: <200703290829.l2T8TE9r000701@anubis.freenet.am> <20070329130723.GC22226@karelia> <200703291023.37354.tmaenner@aehr.com> Message-ID: <20070329213047.GA23612@karelia> Hi Thomas, Thomas Maenner <tmaenner@aehr.com> writes: > Rather than which we would prefer, how about and / or? That's exactly what we are trying to figure out: whether to support just Doxygen or both. I guess it will be both. thanks, -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/20070329/1cf170eb/attachment.pgp From boris at codesynthesis.com Fri Mar 30 13:06:15 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] New idea for stream insertion & extraction In-Reply-To: <F1886AFB628EA94098943970F1563B89CA5512@LINUS.proteus-technologies.com> References: <F1886AFB628EA94098943970F1563B89CA5512@LINUS.proteus-technologies.com> Message-ID: <20070330170615.GC25761@karelia> Hi Ray, Ray Lischner <rlischner@proteus-technologies.com> writes: > One thing missing from the current system, however, is any notion of > structure. Having low-level data without structure is fine for CDR, > but doesn't work as well for, say, ASN.1 DER. I am willing to explore this. However, my two primary concerns are these: 1. The result should be as efficient as it is now for structureless formats like CDR. 2. The result should be generic enough to at least cover some class of formats, not just, say ASN.1 DER. My primary concern is with (2). Since I don't know the details of your custom binary format, let's assume for the moment we are trying to support ASN.1 DER. I am by no means an expert in this format so if I make any mistakes, please correct me. > Here's an idea I recently had for how to add structure to stream > insertion & extraction. This scheme is low-cost, but affects the > code generator. Simply, add a requirement that the stream insertion > and extraction classes have member functions: start(char const*) and > end(char const*). The code generator generates suitable calls to > these functions. After that, it's entirely up the stream class to > deal with that information. > > The ACE CDR stream classes would implement them as inline empty > functions, so there would be nearly no cost. An ASN.1 DER class > would use the start and end functions to generate structure tags. First of all, I don't see how tag names are helpful in DER at all. My understanding is that DER tags are type identifiers, not instance names. For example, if you have two elements, "a" and "b", of type string, then their tags are going to be the same, right? It also seems to me like a lot more needs to be done in order to support DER. For example, right now I encode sequences as length followed by individual items. This will need to be changed since in DER one needs to output sequence tag first, followed by size in octets (which, BTW, I have no way to calculate). The same for optional. > <complexType name="point"> > <sequence> > <element name="x" type="int"/> > <element name="y" type="int"/> > </sequence> > </complexType> > <element name="origin" type="point"/> > > [...] > > Stream extraction is a little harder. The stream extraction constructor > could take another argument for the element name (here is the unavoidable > cost, even if the steam classes ignore the name and structure, passing > the name argument imposes a small cost): > > point::point(xsd::cxx::tree::istream<S>& s, > xml_schema::flags f, > xml_schema::type* c, > char const* name) > : xml_schema::type(s, f, c, name), > _xsd_x_(s, f, this, "x"), > _xsd_y_(s, f, this, "y") > { > s.end(name); > } > > The type::type constructor calls s.start(name) in its body, and other > classes would call end(). Why does the type need to know about the tag in extraction? Why not just let the caller call begin/end: point::point(xsd::cxx::tree::istream<S>& s, xml_schema::flags f, xml_schema::type* c) : xml_schema::type(s, f, c), _xsd_x_(f, this), _xsd_y_(f, this) { { s.begin ("x"); s >> _xsd_x_; s.end ("x"); } { s.begin ("y"); s >> _xsd_y_; s.end ("y"); } } > We have a binary format (similar in spirit to ASN.1 DER) that preserves > data structure, and identifies all data with unique binary IDs. Is it a "tag" ID or "type" ID? Will the two elements above ("x", and "y") have the same ID? > What we want to do is use stream insertion and extraction, but in a way > that preserves the structure. We need to know when each element starts > and ends. We also need to know the identity of each element. I am not sure what you mean by "identity of each element". Can you elaborate a bit on this. Maybe show an example encoding? > We can use the name and lookup the corresponding ID, or even better > would be for Code Synthesis to support some kind of dictionary so it > could encode binary IDs directly in the generated code. I am lost here as well. > (I'm not familiar with the details of Fast Infoset, but I think our > requirements are similar.) If I am not mistaken, FI has a name pool that is referenced by index from the document body. thanks, -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/20070330/647b9697/attachment.pgp From mhoffm1060 at aol.com Fri Mar 30 13:35:40 2007 From: mhoffm1060 at aol.com (mhoffm1060@aol.com) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Reentrant parser? Message-ID: <8C94108F87B3D14-678-19A5@WEBMAIL-RD12.sysops.aol.com> I was wondering if the xml parsing method ( for istreams ) is reentrant? ( Or does each call to the method use the same instance of the Xerces parser? ) Basically I have an object that can potentially try to parse two XML files in different thread contexts, and it is crashing in the Xerces DLL ). Thank, Mark ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. From boris at codesynthesis.com Fri Mar 30 13:30:47 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Reentrant parser? In-Reply-To: <8C94108F87B3D14-678-19A5@WEBMAIL-RD12.sysops.aol.com> References: <8C94108F87B3D14-678-19A5@WEBMAIL-RD12.sysops.aol.com> Message-ID: <20070330173047.GD25761@karelia> Hi Mark, mhoffm1060@aol.com <mhoffm1060@aol.com> writes: > I was wondering if the xml parsing method ( for istreams ) is reentrant? Yes, it is. > ( Or does each call to the method use the same instance of the Xerces > parser? ) No, each call creates a new parser. > Basically I have an object that can potentially try to parse two XML > files in different thread contexts, and it is crashing in the Xerces DLL ). You will need to call xercesc::XMLPlatformUtils::Initialize() and xercesc::XMLPlatformUtils::Terminate() in your main() as well as pass the xml_schema::flags::dont_initialize to the parsing function. Xerces-C++ Initialize() and Terminate() are not safe to call from separate threads and that's exactly what may happen when you call one of the parsing functions from two different threads. hth, -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/20070330/5e38a32c/attachment.pgp From mhoffm1060 at aol.com Fri Mar 30 14:09:37 2007 From: mhoffm1060 at aol.com (mhoffm1060@aol.com) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Reentrant parser? In-Reply-To: <20070330173047.GD25761@karelia> References: <8C94108F87B3D14-678-19A5@WEBMAIL-RD12.sysops.aol.com> <20070330173047.GD25761@karelia> Message-ID: <8C9410DB64EEB24-678-1B10@WEBMAIL-RD12.sysops.aol.com> Boris, That took care of it. Thanks for your quick response. Mark -----Original Message----- From: boris@codesynthesis.com To: mhoffm1060@aol.com Cc: xsd-users@codesynthesis.com Sent: Fri, 30 Mar 2007 10:30 AM Subject: Re: [xsd-users] Reentrant parser? Hi Mark, mhoffm1060@aol.com <mhoffm1060@aol.com> writes: > I was wondering if the xml parsing method ( for istreams ) is reentrant? Yes, it is. > ( Or does each call to the method use the same instance of the Xerces > parser? ) No, each call creates a new parser. > Basically I have an object that can potentially try to parse two XML > files in different thread contexts, and it is crashing in the Xerces DLL ). You will need to call xercesc::XMLPlatformUtils::Initialize() and xercesc::XMLPlatformUtils::Terminate() in your main() as well as pass the xml_schema::flags::dont_initialize to the parsing function. Xerces-C++ Initialize() and Terminate() are not safe to call from separate threads and that's exactly what may happen when you call one of the parsing functions from two different threads. hth, -boris ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.