From EFitzsimmons at cantorgaming.com Fri Nov 7 13:56:48 2008 From: EFitzsimmons at cantorgaming.com (Fitzsimmons, Eric) Date: Fri Nov 7 13:56:58 2008 Subject: [xsde-users] Working with porly formed legacy xml Message-ID: <1D11EEBF3C35004C9CBB14CA39777813961D65@TBEXCHMBXPDVS01.na.ad.espeed.com> I have some legacy code that has a circular dependency between the parsers within the xml. I've seen the file per type information and have run the command to generate these classes, but I still don't see how it solves this problem. Here is an example of what the xml looks like. //////////////////////start XML//////////////////////// ///////////////////////end XML////////////////////////// The schema for this looks like.. //////////////////////start XSD///////////////////////// ///////////////////////end XSD////////////////////////// Now when I generate the code I get 3 pskel classes, object, field, and array. Fields have array and arrays have fields, so when I generate an array or field parser it goes into a creating loop or creating the other type. Is there a way to lazy load this, or is there a way for me to specify in the xsd a way to parse a(this) particular xml? I know the xml is very difficult to work with and could be done easily if the server could return well-formed xml, but at this point in time, there is no way for us to do that. If someone could provide me with a brief example, or point me to one I may have missed that addresses this issue I would greatly appreciate it. Thanks. This e-mail is confidential. If you are not named above as an addressee or are not the intended recipient of this e-mail, please notify the sender and immediately delete it. E-mails are susceptible to data corruption, interception, falsification, delay, unauthorised amendment and viruses. You should therefore carry out such virus and other checks as you consider appropriate. Cantor Gaming does not accept liability for any such events or any consequences thereof in respect of e-mails sent or received. Copyright and any other intellectual property rights in its contents are the sole property of Cantor Gaming. The contents of e-mails may be monitored for security purposes. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Cantor Gaming. This email was sent to you by Cantor Gaming. Cantor Gaming is the trading name of Cantor G&W Nevada L.P., a Nevada limited partnership with offices located at 135 East 57th Street, New York, New York 10022, and Cantor G&W International L.P., a limited partnership registered in England (registered number LP010479) with registered office One Churchill Place, Canary Wharf, London E14 5RD. From boris at codesynthesis.com Fri Nov 7 15:16:03 2008 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 7 15:21:11 2008 Subject: [xsde-users] Working with porly formed legacy xml In-Reply-To: <1D11EEBF3C35004C9CBB14CA39777813961D65@TBEXCHMBXPDVS01.na.ad.espeed.com> References: <1D11EEBF3C35004C9CBB14CA39777813961D65@TBEXCHMBXPDVS01.na.ad.espeed.com> Message-ID: <20081107201603.GA14121@karelia> Hi Eric, Fitzsimmons, Eric writes: > I have some legacy code that has a circular dependency between the > parsers within the xml. I've seen the file per type information > and have run the command to generate these classes, but I still > don't see how it solves this problem. The file-per-type mode is there to solve a bit different problem, namely, cyclic dependencies between schema files. What you have is recursive parsing. That is, you have a parser that can be called recursively during parsing of its child elements. The generated code fully supports recursive parsing though you will need to be careful if your parser implementations have any state. In this case you may need to use a stack to save the state during parsing (there is one in libxsde/xsde/cxx/parser/state.hxx that is used in the parser skeletons). I gave your schema and XML fragment a quick test using the automatic sample implementation/test driver generation feature: $ xsde cxx-parser --generate-print-impl --generate-test-driver \ --root-element object test.xsd $ g++ -I.../libxsde -o driver *.cxx .../libxsde/xsde/libxsde.a $ ./driver test.xml When I tried to run the test driver on your XML I got a couple of errors: test.xml:10:42: invalid NMTOKEN value test.xml:12:8: mismatched tag test.xml:15:2: mismatched tag The 'some address' value is not a valid NMTOKEN plus there were a coupe of closing tags missing. After fixing those the sample XML looks like so: When I run the test driver on it I get: $ ./driver test.xml name: Person id: 1 type: name value: SomeName type: age value: 35 type: jobs name: Job id: 1 type: firstJob value: true type: Addresses value: some-address Boris