From Davide.Anastasia at qualitycapital.com Wed Apr 4 07:30:03 2012 From: Davide.Anastasia at qualitycapital.com (Davide Anastasia) Date: Wed Apr 4 07:30:15 2012 Subject: [xsd-users] XSD, Google Protocol Buffer and Fix Protocol Message-ID: Hi All, First message on this mailing list. J I have a crazy idea, and I don't know whether it's doable or not. I'm currently working on a messaging system based on Apache Qpid. This message middleware doesn't define the format of the message content, so I decided to go for Google Protocol Buffer to serialization C++ objects. However, I would love to us the FIX protocol to define what the content of these messages is. Question: is it possible to generate C++ classes with XSD from the FIX protocol XSD Schema and then plug inside GProto as binary serialization engine (in a similar way like the one described for ACE (Adaptive Communication Environment) CDR streams in the CS XSD manual). Is this completely crazy? J Best, Davide Anastasia Analyst, Research & Development Quality Capital Management Ltd. QCM House * Horizon Business Village No. 1 Brooklands Road Weybridge * Surrey KT13 0TJ United Kingdom Tel: +44 (0) 1932 334 400 Fax: +44 (0) 1932 334 415 Email: Davide.Anastasia@QualityCapital.com www.qualitycapital.com ________________________________ This email and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Quality Capital Management Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, printing, forwarding or copying of this email is strictly prohibited. Please contact the sender if you have received this email in error. You should also be aware that emails are susceptible to interference and you should not assume that the contents of this email originated from the sender above or that they have been accurately reproduced in their original form. Quality Capital Management Ltd is authorised and regulated by the Financial Services Authority in the UK and is a member of the National Futures Association in the US. ________________________________ From boris at codesynthesis.com Fri Apr 6 10:38:03 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Apr 6 10:33:31 2012 Subject: [xsd-users] XSD, Google Protocol Buffer and Fix Protocol In-Reply-To: References: Message-ID: Hi Davide, Davide Anastasia writes: > Question: is it possible to generate C++ classes with XSD from the FIX > protocol XSD Schema and then plug inside GProto as binary serialization > engine (in a similar way like the one described for ACE (Adaptive > Communication Environment) CDR streams in the CS XSD manual). This will be possible if Protocol Buffers provide support for creating binary representations programmatically. Or, in other words, instead of giving Protocol Buffers a class generated from a message specification, we tell it to write/read int, string, etc. If that's possible, then you can implement an XSD binary stream on top of this API as shown in the binary/boost example (there we use the Boost Serialization library). Also, if this is not possible directly, then I suppose you could always define a set of messages each containing a single simple type and then use those messages as a way to serialize the data. I am not sure how efficient this will be, however. Yet another alternative will be to just save the XSD-generated class into one of the supported binary formats (e.g, XDR, CDR, Boost, or something custom) and then add that binary as a blob to the message. It seems this thread discusses this approach: http://groups.google.com/group/protobuf/browse_thread/thread/abd65bfadb8b3439 Boris From douglinhardt at motorolasolutions.com Fri Apr 13 10:45:45 2012 From: douglinhardt at motorolasolutions.com (LINHARDT DOUGLAS-VJKP74) Date: Fri Apr 13 12:02:09 2012 Subject: [xsd-users] Using --file-per-type and importing Message-ID: <931422A5F4941148BCC5F3175E31B7C7122E34F9@SN2PRD0410MB383.namprd04.prod.outlook.com> Hi, I want to be able to use XML Schema to define a set of messages to be sent around my system. I defined a base Message type (in the BaseMessageSchema namespace) in BaseMessage.xsd, and a set of derived messages (in the DerivedMessageSchema namespace) in DerivedMessages.xsd, importing BaseMessage.xsd. When I compile DerivedMessages.xsd without --file-per-type, I generate only DerivedMessages.*. If I compile DerivedMessages.xsd with the --file-per-type, I get the DerivedMessages* and files for all of the types defined within DerivedMessages.xsd. This I expected. However, I also got BaseMessage.* and Message.* files. This I did not expect. I also tried putting the derived messages in the same namespace as the base Message type and including BaseMessage.xsd, but I got the same result. I prefer to have files for each of the types-I think it's easier for a developers looking for a method name for a specific class. However, the derived message types will be spread out all over the file system, and I don't want to re-generate the BaseMessage.*and Message.* files in every directory where derived files are generated. Why is the behavior of file-per-type and file-per-schema different here? I get what I am looking for with file-per-schema, but not with file-per-type. File-per-schema is not a deal-breaker, but it would be nice to generate file-per-type, excluding imported and included types. Thanks. Doug Linhardt From boris at codesynthesis.com Fri Apr 13 14:05:13 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Apr 13 14:01:05 2012 Subject: [xsd-users] Using --file-per-type and importing In-Reply-To: <931422A5F4941148BCC5F3175E31B7C7122E34F9@SN2PRD0410MB383.namprd04.prod.outlook.com> References: <931422A5F4941148BCC5F3175E31B7C7122E34F9@SN2PRD0410MB383.namprd04.prod.outlook.com> Message-ID: Hi Doug, LINHARDT DOUGLAS-VJKP74 writes: > I want to be able to use XML Schema to define a set of messages to be sent > around my system. I defined a base Message type (in the BaseMessageSchema > namespace) in BaseMessage.xsd, and a set of derived messages (in the > DerivedMessageSchema namespace) in DerivedMessages.xsd, importing > BaseMessage.xsd. > > When I compile DerivedMessages.xsd without --file-per-type, I generate only > DerivedMessages.*. The default mode is file-per-schema and you need to compile each schema file, including included and imported ones (except for chameleon inclusion). > If I compile DerivedMessages.xsd with the --file-per-type, I get the > DerivedMessages* and files for all of the types defined within > DerivedMessages.xsd. This I expected. However, I also got BaseMessage.* and > Message.* files. This I did not expect. I also tried putting the derived > messages in the same namespace as the base Message type and including > BaseMessage.xsd, but I got the same result. In the file-per-type mode XSD generates a set of C++ files for each type defined in the schema, including from included and imported schema. It also generates C++ files corresponding to the schema files which generally contain two things: #include directives for all the files corresponding to the type defined by this schema and parsing/serialization functions corresponding to the global elements defined in this schema. If you don't need parsing/serialization functions, then you can ignore these second kind of files (for the next release of XSD we also have added the --fat-type-file option which triggers the generation of code corresponding to global elements into type files instead of schema files; if you are interested I can build you a pre-release with this feature). > I prefer to have files for each of the types-I think it's easier for a > developers looking for a method name for a specific class. However, the > derived message types will be spread out all over the file system, and I > don't want to re-generate the BaseMessage.*and Message.* files in every > directory where derived files are generated. There is a way to make all the derived messages use one set of Message.* files with the --include-regex option (they will still be generated when you compile the derived schemas, but then you can ignore/remove them). The more straightforward approach, however, would be to define each derived message in a separate schema and then use the file-per-schema mode. This way your schema and your C++ files will have the same structure. > Why is the behavior of file-per-type and file-per-schema different here? I > get what I am looking for with file-per-schema, but not with file-per-type. > > File-per-schema is not a deal-breaker, but it would be nice to generate > file-per-type, excluding imported and included types. The file-per-type mode's primary purpose is to handle certain schemas that have inclusion cycles involving inheritance. It is impossible to generate correct code for such schemas without knowing the complete set of types. Boris From bhartsb at gmail.com Wed Apr 18 12:48:08 2012 From: bhartsb at gmail.com (B Hart) Date: Wed Apr 18 12:48:16 2012 Subject: [xsd-users] RFC: Using XML and XSD as a replacement for GUI Message-ID: I've been pondering the appropriateness of using XML files for the following related purposes: 1) Specifying the attributes/properties for creating class objects in a program. 2) Specifying commands that control class objects construction, destruction and behavior. 3) Receiving/reporting status information about the program, or program's given objects and processes. 1 is simply configuration information that gets read in once and used. 2 and 3 are more interactive and require enumerating a folder and comparing the XML file's modified date with the previous one. If modified then re-read the XML file, check for what has changed and react appropriately. As long as the program to XML file interaction is not too fast I don't see any reason not to use XML in this way. What is "too fast" depends on the type of Hard Disk (or array of HDs) and the number of IO operations the HD or array supports. I'm thinking that using XML files this way as perhaps preferable to writing a GUI application to control a program's operations. CodeSynthesis XSD makes handling changes to the XML pretty easy, and I believe easier and more organized/manageable than updating a GUI application. The only caveat I see is that writing the XML files needs to be synchronized. Comments are very welcome. Thanks. From lixia at ge.com Tue Apr 24 19:26:35 2012 From: lixia at ge.com (Li, Xiaoxing (GE Global Research)) Date: Wed Apr 25 03:15:39 2012 Subject: [xsd-users] parser xsd file recursively Message-ID: <67F8BAADB3EBA34CAF11625ADBB46E890171CD8E@CINMLVEM11.e2k.ad.ge.com> Hello, I am trying to use xsd 3.3.0 to generate c++ mapping for a set of .xsd files defined recursively. I.e, I have a "all.xsd", where a bunch of other xsd files are included as . I tried to use ]$ ..bin/xsd cxx-parser --xml-parser expat all.xsd, but the c++ mappings are not generated for all the included files. I am wondering if there is a way of parsing all the xsd files recursively using xsd 3.3.0. Any information will be greatly appreciated. Best Ginger From boris at codesynthesis.com Wed Apr 25 11:31:52 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Apr 25 11:28:14 2012 Subject: [xsd-users] parser xsd file recursively In-Reply-To: <67F8BAADB3EBA34CAF11625ADBB46E890171CD8E@CINMLVEM11.e2k.ad.ge.com> References: <67F8BAADB3EBA34CAF11625ADBB46E890171CD8E@CINMLVEM11.e2k.ad.ge.com> Message-ID: Xiaoxing, Li, Xiaoxing (GE Global Research) writes: > I am trying to use xsd 3.3.0 to generate c++ mapping for a set of .xsd > files defined recursively. I.e, I have a "all.xsd", where a bunch of > other xsd files are included as > > . > > I tried to use > > ]$ ..bin/xsd cxx-parser --xml-parser expat all.xsd, > > but the c++ mappings are not generated for all the included files. I am > wondering if there is a way of parsing all the xsd files recursively > using xsd 3.3.0. By default, XSD requires that you compile each included/imported schema separately. If all your schemas are in the same directory, then you can do it like this: $ .../bin/xsd cxx-parser --xml-parser expat *.xsd There is also the file-per-type mode (activated with the --file-per-type option) which will generate code for all the included/imported schemas in one go. But it will also generate a separate set of C++ files for each schema type. You read more about this mode in this reply to a similar question: http://www.codesynthesis.com/pipermail/xsd-users/2012-April/003613.html Boris From Joakim.Wallman at gyros.com Thu Apr 26 09:55:51 2012 From: Joakim.Wallman at gyros.com (Wallman, Joakim) Date: Thu Apr 26 09:56:01 2012 Subject: [xsd-users] Using template to serialize and deserialize Message-ID: <3E241A73E8CCB040B5DF893008BB19C70395BA72@VIEX01SE.ad-gyrosmicro.com> Hi! When we generate code with the Codesynthesis XSD we get serialization and parsing functions as global (not defined in the class) functions. Is there any way to generate so these functions will be static in the class and have same name for all classes so it is possible to use template to minimize the code? Regards Joakim From boris at codesynthesis.com Thu Apr 26 10:58:24 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Apr 26 10:54:50 2012 Subject: [xsd-users] Using template to serialize and deserialize In-Reply-To: <3E241A73E8CCB040B5DF893008BB19C70395BA72@VIEX01SE.ad-gyrosmicro.com> References: <3E241A73E8CCB040B5DF893008BB19C70395BA72@VIEX01SE.ad-gyrosmicro.com> Message-ID: Hi Joakim, Wallman, Joakim writes: > When we generate code with the Codesynthesis XSD we get serialization and > parsing functions as global (not defined in the class) functions. Is there > any way to generate so these functions will be static in the class and have > same name for all classes so it is possible to use template to minimize the > code? No, this won't be possible because parsing functions will only differ by the return type. If you are looking for a uniform way to perform parsing/serialization, then you may want to consider using the element type and element map features. See the 'messaging' example and Section 2.9, "Mapping for Global Elements" in the C++/Tree Mapping Manual: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.9 Boris From boris at codesynthesis.com Thu Apr 26 12:23:07 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Apr 26 12:19:32 2012 Subject: [xsd-users] parser xsd file recursively In-Reply-To: <67F8BAADB3EBA34CAF11625ADBB46E890171D17A@CINMLVEM11.e2k.ad.ge.com> References: <67F8BAADB3EBA34CAF11625ADBB46E890171CD8E@CINMLVEM11.e2k.ad.ge.com> <67F8BAADB3EBA34CAF11625ADBB46E890171D17A@CINMLVEM11.e2k.ad.ge.com> Message-ID: Hi Xiaoxing, In the future please keep your replies CC'ed to the xsd-users mailing list as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml Li, Xiaoxing (GE Global Research) writes: > Thanks so much for your prompt reply. I am fine with the way of > generating a separate set of C++ files for each schema type. In fact I > prefer this way to maintain the structure of my abstract classes. > Otherwise I could simply write a script to import all the included xsd > files into "all.xsd", and do the parsing into a super large c++ > file(this works). > > Now, as you suggested, I tried to do it in a *.xsd way, but there are > some dependency between the files to be included, thus I am getting a > lot of errors. Are there ways to go around this? Thanks again for your > time. If you are using the file-per-type mode, then you only need to compile the top schema (e.g., all.xsd), not all the schemas. Try something like this: $ xsd ... --file-per-type all.xsd Boris From lixia at ge.com Thu Apr 26 12:51:39 2012 From: lixia at ge.com (Li, Xiaoxing (GE Global Research)) Date: Thu Apr 26 13:39:25 2012 Subject: [xsd-users] parser xsd file recursively In-Reply-To: References: <67F8BAADB3EBA34CAF11625ADBB46E890171CD8E@CINMLVEM11.e2k.ad.ge.com> <67F8BAADB3EBA34CAF11625ADBB46E890171D17A@CINMLVEM11.e2k.ad.ge.com> Message-ID: <67F8BAADB3EBA34CAF11625ADBB46E890175FC95@CINMLVEM11.e2k.ad.ge.com> Hello, Boris This worked perfectly, thanks a lot! Best Ginger -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Thursday, April 26, 2012 12:23 PM To: Li, Xiaoxing (GE Global Research) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] parser xsd file recursively Hi Xiaoxing, In the future please keep your replies CC'ed to the xsd-users mailing list as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml Li, Xiaoxing (GE Global Research) writes: > Thanks so much for your prompt reply. I am fine with the way of > generating a separate set of C++ files for each schema type. In fact I > prefer this way to maintain the structure of my abstract classes. > Otherwise I could simply write a script to import all the included xsd > files into "all.xsd", and do the parsing into a super large c++ > file(this works). > > Now, as you suggested, I tried to do it in a *.xsd way, but there are > some dependency between the files to be included, thus I am getting a > lot of errors. Are there ways to go around this? Thanks again for your > time. If you are using the file-per-type mode, then you only need to compile the top schema (e.g., all.xsd), not all the schemas. Try something like this: $ xsd ... --file-per-type all.xsd Boris