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