From Eric.Broadbent at csr.com Wed Nov 2 13:32:51 2011 From: Eric.Broadbent at csr.com (Eric Broadbent) Date: Wed Nov 2 14:00:49 2011 Subject: [xsd-users] error processing multiple schemas at once Message-ID: Hi fellow XSD users - I'm new to the community and am hoping to use XSD to generate some parsing code for a schema defining information I need to process. I ran XSD to generate parsing code for a single schema (defined elsewhere),specifying the "--root-element" option, so that it would generate the test driver. It generated subset_schema-driver.cxx and .hxx, subset_schema-pskel.cxx and .hxx files just fine. However I got these errors when I attempted to compile the generated code: subset_schema-pskel.hxx:465:50: error: shared-types-pskel.hxx: No such file or directory subset_schema-pskel.hxx:467:50: error: shared-resources-pskel.hxx: No such file or directory Obviously, the subset_schema.xsd referenced other schemas, so I searched and found this in the archives - in the release notes for 2.3.1 (or something like that) "The compiler is now capable of translating multiple schemas with one invocation." So I tried running XSD with multiple schemas: (same command as I used originally but just added the other schemas on the end) xsd cxx-parser --show-sloc --force-overwrite --show-anonymous --root-element subset_root --generate-test-driver --generate-print-impl --generate-validation --xml-parser expat subset_schema.xsd shared-types.xsd shared-resources xsd This time, it didn't appear to accept the "--root-element" option" xsd: error: unable to generate the test driver without a global element (document root) Maybe I need to somehow specify it for each schema? Any assistance would be greatly appreciated - thanks! EBroadbent Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog From boris at codesynthesis.com Wed Nov 2 15:27:59 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 2 15:29:13 2011 Subject: [xsd-users] error processing multiple schemas at once In-Reply-To: References: Message-ID: Hi Eric, Eric Broadbent writes: > So I tried running XSD with multiple schemas: (same command as I used > originally but just added the other schemas on the end) > > xsd cxx-parser --show-sloc --force-overwrite --show-anonymous > --root-element subset_root --generate-test-driver --generate-print-impl > --generate-validation --xml-parser expat subset_schema.xsd shared-types.xsd > shared-resources xsd > > This time, it didn't appear to accept the "--root-element" option" > > xsd: error: unable to generate the test driver without a global > element (document root) When you specify --generate-test-driver, XSD will try to generate a driver for each schema you passed. If there is no global element in any of them, then you will get the above error. The solution to this is to compile the "included/imported" schemas without this option and then compile the "root" schema (the one that defines the global element) separately with this option: xsd cxx-parser --show-sloc --force-overwrite --show-anonymous --generate-print-impl --generate-validation --xml-parser expat shared-types.xsd shared-resources.xsd xsd cxx-parser --show-sloc --force-overwrite --show-anonymous --root-element subset_root --generate-test-driver --generate-print-impl --generate-validation --xml-parser expat subset_schema.xsd Boris From Eric.Broadbent at csr.com Wed Nov 2 16:41:26 2011 From: Eric.Broadbent at csr.com (Eric Broadbent) Date: Wed Nov 2 16:41:24 2011 Subject: [xsd-users] error processing multiple schemas at once In-Reply-To: References: Message-ID: <176C7A1B-3F29-4C83-BD0D-670A7EF180F5@csr.com> Hi Boris - thanks very much for your reply. After I send off my query I realized that running it separately was probably the thing I needed to do and had to divert to something else before I could try that. Makes sense to have only one driver generated, so supplying more than one "root-element" option is not meaningful I guess. I'll try this and report back if it doesn't work as expected. Many thanks. -Eric B. On Nov 2, 2011, at 3:27 PM, Boris Kolpackov wrote: > Hi Eric, > > Eric Broadbent writes: > >> So I tried running XSD with multiple schemas: (same command as I used >> originally but just added the other schemas on the end) >> >> xsd cxx-parser --show-sloc --force-overwrite --show-anonymous >> --root-element subset_root --generate-test-driver --generate-print-impl >> --generate-validation --xml-parser expat subset_schema.xsd shared-types.xsd >> shared-resources xsd >> >> This time, it didn't appear to accept the "--root-element" option" >> >> xsd: error: unable to generate the test driver without a global >> element (document root) > > When you specify --generate-test-driver, XSD will try to generate a > driver for each schema you passed. If there is no global element in > any of them, then you will get the above error. The solution to this > is to compile the "included/imported" schemas without this option and > then compile the "root" schema (the one that defines the global element) > separately with this option: > > xsd cxx-parser --show-sloc --force-overwrite --show-anonymous > --generate-print-impl --generate-validation --xml-parser expat > shared-types.xsd shared-resources.xsd > > xsd cxx-parser --show-sloc --force-overwrite --show-anonymous > --root-element subset_root --generate-test-driver --generate-print-impl > --generate-validation --xml-parser expat subset_schema.xsd > > Boris > > > To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== . Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog From abhave at telcordia.com Thu Nov 3 18:57:04 2011 From: abhave at telcordia.com (Bhave, Abhay V) Date: Fri Nov 4 09:26:19 2011 Subject: [xsd-users] Help needed - codesynthesis on HP-UX 11.31 with aC++ using xsd:choice Message-ID: <90386C62D037DB46A02FEF929FB183702835C1C8AC@rrc-dte-exmb2.dte.telcordia.com> HP-UX B.11.31 U ia64 Generated hxx and cxx files from my XSDs. I need help trying to parse a given XML. The XSD is like below ------ ----- --- Using the document and example as a guide my code like below auto_ptr getDetailsRespPtr(0); getDetailsRespPtr = Job::v1::GetDetailsResp_(argv[1], flags::dont_validate); ( getDetailsRespPtr.get())->Work(); Question: how do I figure out the type of Work? Any help is appreciated. Abhay From boris at codesynthesis.com Fri Nov 4 09:34:39 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 4 09:36:19 2011 Subject: [xsd-users] Help needed - codesynthesis on HP-UX 11.31 with aC++ using xsd:choice In-Reply-To: <90386C62D037DB46A02FEF929FB183702835C1C8AC@rrc-dte-exmb2.dte.telcordia.com> References: <90386C62D037DB46A02FEF929FB183702835C1C8AC@rrc-dte-exmb2.dte.telcordia.com> Message-ID: Hi Abhay, Bhave, Abhay V writes: > > > > > > [...] > > > > [...] > > > > Using the document and example as a guide my code like below > > auto_ptr getDetailsRespPtr(0); > getDetailsRespPtr = Job::v1::GetDetailsResp_(argv[1], flags::dont_validate); > ( getDetailsRespPtr.get())->Work(); > > Question: how do I figure out the type of Work? I am not sure I understand your question. From the schema you can see that the Work element is of the GetJobWork type. So there will be a C++ class Job::v1::GetJobWork. Also note that in your schema the Work element is inside a choice compositor. In the C++/Tree mapping this means that the resulting C++ member will be of the "optional" cardinality. To access such an element you would need to write something like this: if (getDetailsRespPtr->Work ().present ()) { Job::v1::GetJobWork& w (getDetailsRespPtr->Work ().get ()); } For more information on different member cardinalities and how to access them, please read the first two sections in Chapter 4, "Working with Object Models" in the C++/Tree Mapping Getting Started Guide: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#4 Boris From masyukun at gmail.com Fri Nov 4 20:55:34 2011 From: masyukun at gmail.com (Matt Royal) Date: Fri Nov 4 21:04:42 2011 Subject: [xsd-users] RE: xsd-users Digest, Vol 77, Issue 2 Message-ID: unsubscribe --Matthew -------- Original message -------- Subject: xsd-users Digest, Vol 77, Issue 2 From: xsd-users-request@codesynthesis.com To: xsd-users@codesynthesis.com CC: Send xsd-users mailing list submissions to xsd-users@codesynthesis.com To subscribe or unsubscribe via the World Wide Web, visit http://codesynthesis.com/mailman/listinfo/xsd-users or, via email, send a message with subject or body 'help' to xsd-users-request@codesynthesis.com You can reach the person managing the list at xsd-users-owner@codesynthesis.com When replying, please edit your Subject line so it is more specific than "Re: Contents of xsd-users digest..." Today's Topics: ?? 1. Help needed - codesynthesis on HP-UX 11.31 with aC++ using ????? xsd:choice (Bhave, Abhay V) ?? 2. Re: Help needed - codesynthesis on HP-UX 11.31 with aC++ ????? using xsd:choice (Boris Kolpackov) ---------------------------------------------------------------------- Message: 1 Date: Thu, 3 Nov 2011 18:57:04 -0400 From: "Bhave, Abhay V" Subject: [xsd-users] Help needed - codesynthesis on HP-UX 11.31 with aC++ using xsd:choice To: "'xsd-users@codesynthesis.com'" Message-ID: <90386C62D037DB46A02FEF929FB183702835C1C8AC@rrc-dte-exmb2.dte.telcordia.com> Content-Type: text/plain; charset="us-ascii" HP-UX? B.11.31 U ia64 Generated hxx and cxx files from my XSDs. I need help trying to parse a given XML. The XSD is like below ------ ?? ?? ???? ??????????? ?????????????? ?????????????? ?????????????? ?????????????? ??????????? ????? ????? ?? ----- ?? ?? ????? ??????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ?????????????? ??????????? ????? ?? --- Using the document and example as a guide my code like below ??? auto_ptr getDetailsRespPtr(0); ??? getDetailsRespPtr = Job::v1::GetDetailsResp_(argv[1], flags::dont_validate); ??? ( getDetailsRespPtr.get())->Work(); Question: how do I figure out the type of Work? Any help is appreciated. Abhay ------------------------------ Message: 2 Date: Fri, 4 Nov 2011 15:34:39 +0200 From: Boris Kolpackov Subject: Re: [xsd-users] Help needed - codesynthesis on HP-UX 11.31 with aC++ using xsd:choice To: "Bhave, Abhay V" Cc: "'xsd-users@codesynthesis.com'" Message-ID: Content-Type: text/plain; charset=us-ascii Hi Abhay, Bhave, Abhay V writes: >??? >????? >???????????? >??????????????? > > [...] > >??? >?????? > [...] >?????? >??? > > Using the document and example as a guide my code like below > >???? auto_ptr getDetailsRespPtr(0); >???? getDetailsRespPtr = Job::v1::GetDetailsResp_(argv[1], flags::dont_validate); >???? ( getDetailsRespPtr.get())->Work(); > > Question: how do I figure out the type of Work? I am not sure I understand your question. From the schema you can see that the Work element is of the GetJobWork type. So there will be a C++ class Job::v1::GetJobWork. Also note that in your schema the Work element is inside a choice compositor. In the C++/Tree mapping this means that the resulting C++ member will be of the "optional" cardinality. To access such an element you would need to write something like this: if (getDetailsRespPtr->Work ().present ()) { ? Job::v1::GetJobWork& w (getDetailsRespPtr->Work ().get ()); } For more information on different member cardinalities and how to access them, please read the first two sections in Chapter 4, "Working with Object Models" in the C++/Tree Mapping Getting Started Guide: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#4 Boris ------------------------------ _______________________________________________ xsd-users mailing list xsd-users@codesynthesis.com http://codesynthesis.com/mailman/listinfo/xsd-users End of xsd-users Digest, Vol 77, Issue 2 **************************************** From Eric.Broadbent at csr.com Sun Nov 6 01:07:56 2011 From: Eric.Broadbent at csr.com (Eric Broadbent) Date: Sun Nov 6 01:08:03 2011 Subject: [xsd-users] error processing multiple schemas at once In-Reply-To: References: Message-ID: <9DFD5D06-5029-44ED-B35C-61725F226E90@csr.com> Hi Boris, thanks to your previous advice I am now parsing the schemas that I need to, using the printf version of the "pimpl" code. This is great, I'm impressed with the overall implementation. Someday I'll figure out how to write C++ template code... for now I remain in awe of it's power in the hands of people smarter than I am. I have a bunch of work to do now to wire up to this code to construct the in-memory data model, but this is a manageable task. What I don't know how to do is separate the generated code from the built-in library interface, so that I can call the Expat parser myself. The software system I'm working within (a large multipurpose data transformation system) already has Expat being used in another part of it, so I'm somewhat familiar with the Expat interface. The reason that I couldn't just use it as before is that we now need to process a much more complex schema than the existing implementation could handle, so I decided to try XSD instead of our previous schema-handling solution. The generated pskel and pimpl code works well, but the standalone executable is almost 15MB (I built with validation on) and of course it brings in std:: versions of utilities that already exist in the software environment that I want to plug the parser into. One example is simply malloc - we have our own system-wide malloc, and other services, and we call XML_ParserCreate_MMR to be able to utilize it. Here's the stack when the Expat XML parser is created - in the generated driver executable: Breakpoint 10, 0x00007fff8939287f in XML_ParserCreateNS () (gdb) bt #0 0x00007fff8939287f in XML_ParserCreateNS () #1 0x000000010003b652 in xsd::cxx::parser::expat::document::parse (this=0x7fff5fbfc4d0, is=@0x7fff5fbed480, system_id=0x7fff5fbfec90, public_id=0x0, eh=@0x7fff5fbfc510) at elements.txx:281 #2 0x000000010003b986 in xsd::cxx::parser::expat::document::parse (this=0x7fff5fbfc4d0, is=@0x7fff5fbed480, system_id=@0x7fff5fbfec90) at elements.txx:134 #3 0x000000010003ba32 in xsd::cxx::parser::expat::document::parse (this=0x7fff5fbfc4d0, file=@0x7fff5fbfec90) at elements.txx:96 #4 0x0000000100007470 in main (argc=2, argv=0x7fff5fbfede8) at sub-driver.cxx:1884 What I'd like to do is be able to set up and if possible even invoke the Expat interface from my code - of course complying with all requirements XSD and Expat, instead of from within the xsd::cxx::parser::expat:: template-derived code. Is this possible? Am I misunderstanding how this all has to hang together? Does the generated code require stuff in xsd:: or xsd::cxx:: or any of the other parts of the XSD library that I cannot substitute with entrypoints in my existing software? The main(...) entrypoint in the generated driver code sets up all the parsers and then processes the document with code like this: - - - - - - - - - - - - - - - - - - - - - - - - - - - // Parse the XML document. // ::xml_schema::document doc_p ( CT_Top_p, "http://repository.schemas/xdata", "top"); CT_Top_p.pre (); doc_p.parse (argv[1]); CT_Top_p.post_CT_Top (); } - - - - - - - - - - - - - - - - - - - - - - - - - - - Instead of this, I wonder if it is possible to call XML_Parse myself, after setting the element handler to the top-level object (CT_Top_p). The question is whether I can then automagically cascade through the elements - something that is taken care of so nicely in XSD. The current Expat code in our software application suite has a list of valid elements attached to each element and does a linear search through them to find each subsequent element provided by Expat - but that is likely not a method one would want to try to use in conjunction with the XSD-generated code. Interested to hear your thoughts, and I very much appreciate your help. -Eric B. On Nov 2, 2011, at 3:27 PM, Boris Kolpackov wrote: > Hi Eric, > > Eric Broadbent writes: > >> So I tried running XSD with multiple schemas: (same command as I used >> originally but just added the other schemas on the end) >> >> xsd cxx-parser --show-sloc --force-overwrite --show-anonymous >> --root-element subset_root --generate-test-driver --generate-print-impl >> --generate-validation --xml-parser expat subset_schema.xsd shared-types.xsd >> shared-resources xsd >> >> This time, it didn't appear to accept the "--root-element" option" >> >> xsd: error: unable to generate the test driver without a global >> element (document root) > > When you specify --generate-test-driver, XSD will try to generate a > driver for each schema you passed. If there is no global element in > any of them, then you will get the above error. The solution to this > is to compile the "included/imported" schemas without this option and > then compile the "root" schema (the one that defines the global element) > separately with this option: > > xsd cxx-parser --show-sloc --force-overwrite --show-anonymous > --generate-print-impl --generate-validation --xml-parser expat > shared-types.xsd shared-resources.xsd > > xsd cxx-parser --show-sloc --force-overwrite --show-anonymous > --root-element subset_root --generate-test-driver --generate-print-impl > --generate-validation --xml-parser expat subset_schema.xsd > > Boris > > > To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== . Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog From boris at codesynthesis.com Mon Nov 7 08:39:59 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 7 08:42:22 2011 Subject: [xsd-users] error processing multiple schemas at once In-Reply-To: <9DFD5D06-5029-44ED-B35C-61725F226E90@csr.com> References: <9DFD5D06-5029-44ED-B35C-61725F226E90@csr.com> Message-ID: Hi Eric, Eric Broadbent writes: > What I don't know how to do is separate the generated code from the > built-in library interface, so that I can call the Expat parser myself. Yes, this is possible. See Section 7.2, "Expat Document Parser" in the "C++/Parser Mapping Getting Started Guide": http://www.codesynthesis.com/projects/xsd/documentation/cxx/parser/guide/#7.2 > The generated pskel and pimpl code works well, but the standalone executable > is almost 15MB (I built with validation on) and of course it brings in std:: > versions of utilities that already exist in the software environment that I > want to plug the parser into. One example is simply malloc - we have our > own system-wide malloc, and other services, and we call XML_ParserCreate_MMR > to be able to utilize it. C++/Parser in XSD doesn't allow this level of customization. It will always use "standard C++" facilities where needed. If you want to minimize external dependencies, then you may want to consider XSD/e and its Embedded C++/Parser mapping, which is very similar to C++/Parser. XSD/e is highly configurable, you can enable/ disable individual C++ features (like STL, iostream, exceptions, etc). It also allows you to provide a custom memory allocator. In minimal configuration it doesn't use much more than the basic C standard library functions (strlen, memcpy, etc): http://www.codesynthesis.com/products/xsde/ Boris From Eric.Broadbent at csr.com Mon Nov 7 11:38:18 2011 From: Eric.Broadbent at csr.com (Eric Broadbent) Date: Mon Nov 7 11:38:43 2011 Subject: [xsd-users] error processing multiple schemas at once In-Reply-To: References: <9DFD5D06-5029-44ED-B35C-61725F226E90@csr.com> Message-ID: Hi Boris - indeed it looks like XSD/e is what I should be looking at. The software system that consumes the XML is in fact an embedded system - I just didn't know that there was an XSD implementation designed for this. I will transition to using that in my next iteration - and thanks so much for your help and advice. -Eric B. On Nov 7, 2011, at 8:39 AM, Boris Kolpackov wrote: > Hi Eric, > > Eric Broadbent writes: > >> What I don't know how to do is separate the generated code from the >> built-in library interface, so that I can call the Expat parser myself. > > Yes, this is possible. See Section 7.2, "Expat Document Parser" in the > "C++/Parser Mapping Getting Started Guide": > > http://www.codesynthesis.com/projects/xsd/documentation/cxx/parser/guide/#7.2 > > >> The generated pskel and pimpl code works well, but the standalone executable >> is almost 15MB (I built with validation on) and of course it brings in std:: >> versions of utilities that already exist in the software environment that I >> want to plug the parser into. One example is simply malloc - we have our >> own system-wide malloc, and other services, and we call XML_ParserCreate_MMR >> to be able to utilize it. > > C++/Parser in XSD doesn't allow this level of customization. It will > always use "standard C++" facilities where needed. > > If you want to minimize external dependencies, then you may want to > consider XSD/e and its Embedded C++/Parser mapping, which is very > similar to C++/Parser. XSD/e is highly configurable, you can enable/ > disable individual C++ features (like STL, iostream, exceptions, etc). > It also allows you to provide a custom memory allocator. In minimal > configuration it doesn't use much more than the basic C standard > library functions (strlen, memcpy, etc): > > http://www.codesynthesis.com/products/xsde/ > > Boris > > > To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== . Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog From agarriga at free.fr Thu Nov 10 03:41:27 2011 From: agarriga at free.fr (agarriga@free.fr) Date: Thu Nov 10 03:41:38 2011 Subject: [xsd-users] Error on code generation in c++ from statechart schema "scxml.xsd" In-Reply-To: Message-ID: <7bd5c5de-719a-45d6-ab93-b804b79f6eba@zimbra75-e12.priv.proxad.net> Hi, I would like generate some code from the schemas for SCXML SCXML is State Chart XML (SCXML): State Machine Notation for Control Abstraction I downloaded "xsd" files from the following url http://www.w3.org/TR/scxml/#schemas http://www.w3.org/2011/04/SCXML/ and I don't understand why from files written and validated by the W3C i have the following error with xsd.exe ? I understand "violates the unique particle attribution rule" but i don't know from where the error comes: - a bug in xsd.exe ? - or in scxml.xsd files from W3C ? Command line: xsd.exe cxx-tree scxml.xsd --generate-inline --generate-ostream Error: :0:0: error: complex type 'scxml.finalize.type' violates the unique particle attribution rule in its components '##other ' and '##other' Package used: xsd-3.3.msi OS: Windows7 Thanks Anton From eric.broadbent at csr.com Thu Nov 10 14:06:27 2011 From: eric.broadbent at csr.com (Eric Broadbent) Date: Thu Nov 10 14:06:43 2011 Subject: [xsd-users] error processing multiple schemas at once In-Reply-To: References: <9DFD5D06-5029-44ED-B35C-61725F226E90@csr.com> Message-ID: Hi Boris, when I built XSDE, many serialization files were built - whether or not I set "XSDE_SERIALIZER_VALIDATION" on or off in config..make (Here's a partial listing of the compiles with XSDE_SERIALIZER_VALIDATION := n") g++ -I.. -W -Wall -O3 -c cxx/serializer/elements.cxx -o cxx/serializer/elements.o g++ -I.. -W -Wall -O3 -c cxx/serializer/context.cxx -o cxx/serializer/context.o g++ -I.. -W -Wall -O3 -c cxx/serializer/genx/document.cxx -o cxx/serializer/genx/document.o g++ -I.. -W -Wall -O3 -c cxx/serializer/genx/xml-error.cxx -o cxx/serializer/genx/xml-error.o g++ -I.. -W -Wall -O3 -c cxx/serializer/exceptions.cxx -o cxx/serializer/exceptions.o g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/serializer.cxx -o cxx/serializer/non-validating/serializer.o g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/time-zone.cxx -o cxx/serializer/non-validating/time-zone.o g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/xml-schema-sskel.cxx -o cxx/serializer/non-validating/xml-schema-sskel.o <... 40 lines skipped ...> g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/date-time.cxx -o cxx/serializer/non-validating/date-time.o g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/duration.cxx -o cxx/serializer/non-validating/duration.o I was operating with the understanding that serialization is optional - but perhaps that's only when schema-compilation is run (after XSDE is built). The chapter on Serialization (http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#4) indicates: "Note that the generation of the serialization code is optional and should be explicitly requested with the --generate-serialization option." Secondly, in the software that XSDE will be linked into, Expat exists already. Instead of having the XSDE build process compile another instance of Expat, is it possible for me to just point the XSDE library at the existing build? (Assuming they are the same release of Expat which they are) Thanks again for your help - sorry for all the questions. -Eric On Nov 7, 2011, at 11:38 AM, Eric Broadbent wrote: > Hi Boris - indeed it looks like XSD/e is what I should be looking at. > The software system that consumes the XML is in fact an embedded system - I just didn't know that there was an XSD implementation designed for this. > I will transition to using that in my next iteration - and thanks so much for your help and advice. > > -Eric B. > > On Nov 7, 2011, at 8:39 AM, Boris Kolpackov wrote: > >> Hi Eric, >> >> Eric Broadbent writes: >> >>> What I don't know how to do is separate the generated code from the >>> built-in library interface, so that I can call the Expat parser myself. >> >> Yes, this is possible. See Section 7.2, "Expat Document Parser" in the >> "C++/Parser Mapping Getting Started Guide": >> >> http://www.codesynthesis.com/projects/xsd/documentation/cxx/parser/guide/#7.2 >> >> >>> The generated pskel and pimpl code works well, but the standalone executable >>> is almost 15MB (I built with validation on) and of course it brings in std:: >>> versions of utilities that already exist in the software environment that I >>> want to plug the parser into. One example is simply malloc - we have our >>> own system-wide malloc, and other services, and we call XML_ParserCreate_MMR >>> to be able to utilize it. >> >> C++/Parser in XSD doesn't allow this level of customization. It will >> always use "standard C++" facilities where needed. >> >> If you want to minimize external dependencies, then you may want to >> consider XSD/e and its Embedded C++/Parser mapping, which is very >> similar to C++/Parser. XSD/e is highly configurable, you can enable/ >> disable individual C++ features (like STL, iostream, exceptions, etc). >> It also allows you to provide a custom memory allocator. In minimal >> configuration it doesn't use much more than the basic C standard >> library functions (strlen, memcpy, etc): >> >> http://www.codesynthesis.com/products/xsde/ >> >> Boris >> >> >> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== . > > > > Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom > More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog > From boris at codesynthesis.com Fri Nov 11 05:22:40 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 11 05:25:55 2011 Subject: [xsd-users] Error on code generation in c++ from statechart schema "scxml.xsd" In-Reply-To: <7bd5c5de-719a-45d6-ab93-b804b79f6eba@zimbra75-e12.priv.proxad.net> References: <7bd5c5de-719a-45d6-ab93-b804b79f6eba@zimbra75-e12.priv.proxad.net> Message-ID: Hi Anton, agarriga@free.fr writes: > and I don't understand why from files written and validated by the W3C i > have the following error with xsd.exe ? Some of the worst schemas that we have seen are from W3C. > I understand "violates the unique particle attribution rule" but i don't > know from where the error comes: > > - a bug in xsd.exe ? > - or in scxml.xsd files from W3C ? This depends on the interpretation of the unique particle attribution rule from the XML Schema specification. In the scxml schema there are unbounded sequences of unbounded sequences of the xsd:any wildcards (see the scxml.extra.content group and how it is used). In the strict interpretation of the rule, this is a violation, since there are multiple ways to associate elements to this sequence-of-sequences content model. However, some processors may be able to "see" that this is really just a single sequence and not flag it as an error. The way to "fix" this schema would be to remove the minOccurs="0", maxOccurs="unbounded" from the references to the scxml.extra.content group. Though this will still be in vain since the scxml schemas use the xsd:redefine construct which is not supported by XSD (Just to confirm my point about W3C-designed schemas, it is widely agreed that the xsd:redefine is a mis-feature, should not be used, and will be deprecated in the next W3C XML Schema version. At the same time a W3C working group goes ahead and uses it anyway). Boris From DLickert at testo.de Tue Nov 22 07:07:21 2011 From: DLickert at testo.de (Lickert, Dominik (LEN, DivHG)) Date: Tue Nov 22 07:34:33 2011 Subject: [xsd-users] XSD Parsing with different schema files Message-ID: <7F3DD1431E490D4DB37C698C3EED6F3014A96B6832@TESTOEX001.cds.testo> Hello, I have a problem with the parsing of a Microsoft Visio files. I save my flow chart as *.vdx, which is a XML format. I build source- and header codes with the XSD-tool and the XSD-schema-files of Microsoft Visio. There are three different schema files for Microsoft Visio, which are all needed for the edition 2010. They are not linked to each other, they are separated. So the XSD-tool generates three different source- and header codes. The solution of the problem is to link these three XSD-schema-files together. I think this is possible with the command line attributes of the XSD-tool. I tried it with the command line attributes "namespace-map" and "polymorphic", but without success. There is only in one of the three source code files a parse function. When I parse my Visio file, with this parse function, it doesn't find all elements. Elements of the two other XSD-schema-files are ignored by the parse function. Even all elements in the same level and behind this element of a other schema file are also ignored. The reason for that is, the for-loop is broken, when an element of a other XSD-schema-file occurs. I hope somebody can help me Best Regards Dominik Lickert Testo AG, Lenzkirch, Commercial Register Freiburg 320456 - Board of Directors: Burkart Knospe (CEO), Lothar Walleser, Martin Winkle, Dr. J?rk Hebenstreit- Supervisory board: Anne-Kathrin Deutrich (Chairperson), Klaus Fritzsching, Hartmut Herrlinger, Testo AG, Testo-Strasse 1, 79853 Lenzkirch, Germany From boris at codesynthesis.com Wed Nov 23 10:48:04 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 23 10:54:12 2011 Subject: [xsd-users] XSD Parsing with different schema files In-Reply-To: <7F3DD1431E490D4DB37C698C3EED6F3014A96B6832@TESTOEX001.cds.testo> References: <7F3DD1431E490D4DB37C698C3EED6F3014A96B6832@TESTOEX001.cds.testo> Message-ID: Hi Dominik, Lickert, Dominik (LEN, DivHG) writes: > I have a problem with the parsing of a Microsoft Visio files. I save my > flow chart as *.vdx, which is a XML format. > > I build source- and header codes with the XSD-tool and the XSD-schema-files > of Microsoft Visio. There are three different schema files for Microsoft > Visio, which are all needed for the edition 2010. They are not linked to > each other, they are separated. So the XSD-tool generates three different > source- and header codes. The solution of the problem is to link these three > XSD-schema-files together. I think this is possible with the command line > attributes of the XSD-tool. I tried it with the command line attributes > "namespace-map" and "polymorphic", but without success. > > There is only in one of the three source code files a parse function. > When I parse my Visio file, with this parse function, it doesn't find > all elements. Elements of the two other XSD-schema-files are ignored > by the parse function. Even all elements in the same level and behind > this element of a other schema file are also ignored. The reason for > that is, the for-loop is broken, when an element of a other XSD-schema- > file occurs. It is hard to say exactly why it doesn't work without seeing some concrete examples of the schema types/elements involved. However, generally, if the schemas are separate (you say they are not "linked" by which I assume you mean that there is no xsd:include or xsd:import directive that includes/imports one schema into another), then the only way one schema can use elements from another is indirectly via a wildcard (xsd:any). That is, one schema defines a wildcard and another defines elements which will be substituted for this wildcard. If that's the case, then it is possible to "parse" these elements using parsing code generated from another schema. For sample code that shows how to do this, refer to the 'wildcard' example in the examples/cxx/tree/ directory in the XSD distribution. Actually, there is another case where unrelated schemas can in some sense use each other indirectly. In this situation one of the schemas uses one of the built-in types (normally xsd:anyType) as a base and other schemas extend or restrict this type. The resulting combination can then be used with XML Schema polymorphism (xsi:type). However, this should work our of the box in XSD, provided you have compiled your schemas with the --generate-polymorphic option, marked the base type as polymorphic with the --polymorphic-type option, and linked all the resulting source files into your application. Boris From mjklaim at gmail.com Thu Nov 24 10:17:19 2011 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Thu Nov 24 10:17:27 2011 Subject: [xsd-users] Inheritance : Ways to get the real type Message-ID: Hi, I thought I asked this before but cannot find my message on this list so maybe I just thought about it very hard and didn't ask in the end. The question is simple, I just need a confirmation : Assuming I'm using correctly the xsd inheritance mechanism and get base and child classes in C++ using xsd/tree (not xsde), in C++ (with objects genreated via xsd/tree) the only ways to know what is the real type of an object we got are: 1. use dynamic_cast 2. use typeid Correct? No type name information provided by xsd/tree generated types, right? Or am I missing something? Thanks for your time. Jo?l Lamotte From boris at codesynthesis.com Fri Nov 25 00:47:15 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 25 00:53:45 2011 Subject: [xsd-users] Inheritance : Ways to get the real type In-Reply-To: References: Message-ID: Hi Jo?l, Klaim - Jo?l Lamotte writes: > Assuming I'm using correctly the xsd inheritance mechanism and get base and > child classes in C++ using xsd/tree (not xsde), > in C++ (with objects genreated via xsd/tree) the only ways to know what is > the real type of an object we got are: > > 1. use dynamic_cast > 2. use typeid > > Correct? Yes, that's correct. > No type name information provided by xsd/tree generated types, right? Right. What kind of type information are you looking for? Boris From boris at codesynthesis.com Fri Nov 25 01:12:11 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 25 01:18:44 2011 Subject: [xsd-users] XSD Parsing with different schema files In-Reply-To: <7F3DD1431E490D4DB37C698C3EED6F3014A96B6E0C@TESTOEX001.cds.testo> References: <7F3DD1431E490D4DB37C698C3EED6F3014A96B6832@TESTOEX001.cds.testo> <7F3DD1431E490D4DB37C698C3EED6F3014A96B6E0C@TESTOEX001.cds.testo> Message-ID: Hi Dominik, 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 Lickert, Dominik (LEN, DivHG) writes: > I think that isn't the solution. I tried to build my project with both > variants, but also without success. I have an example of the XML file of > Visio. The three separated schema files are linked to the xml file in the > root element. For reminder: They are linked only in the XML file, not in the > schema files!!! > The elements of the two other schema files, of the namespace "extension", > are: > - "Event" > - "Layout" > - "Protection" > (The content of the elements with a "+" in front of is comment out!!!) I looked at the schemas and indeed they use the first approach I described (wildcards). In particular, look at the vx:Event element under the Shape element in your sample XML. This element is allowed by the xsd:any wildcard in ShapeSheet_Type (visio.xsd, line 157). > My problem is now that the parsing process is interrupted at the point > of the element ' '. > At this point the parser go back to the element "Shape" and parse the next > element after "Shape", in this case the element "Icon". I am not sure what you mean by "interrupted". If you compiled your schemas with the --generate-wildcard option (and following other instructions from the 'wildcard' example), then the content corresponding to the vx:Event element will be stored in the object model as a DOM fragment. This fragment can then be parsed into the object model fragment, again, as shown in the 'wildcard' example. > I hope now it's more clear what I meant. Please ask if not, it's > difficult to explain. > > I added the three schema files. > The download-link of the schema files is here: > http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23976 > > One further problem are errors during the building. The point the > redefinition of a lot of classes. I know that one solution is to map > them with the "--namespace-map" attribute, but I think this is the > wrong way, isn't it? I think this is the information to the solution. The vision.xsd schema declarations are placed into the 'core' C++ namespace, while both visio12.xsd and visio14.xsd are both mapped to the 'extension' C++ namespace. So, yes, you will need to use the --namespace-map option to map the last two files to different C++ namespaces. Boris > > > VISIO_XML EXAMPLE: > > > > - > + > + > + > + > + > + > + > - > -