From andre.vautour at caris.com Thu Jan 8 09:37:00 2015 From: andre.vautour at caris.com (Andre Vautour) Date: Thu Jan 8 09:37:08 2015 Subject: [xsd-users] Restricted NMTOKENS (enumeration) with default value Message-ID: <54AE960C.4030303@caris.com> I ran into a problem with a schema that has an enumeration (xsd:NMTOKENS with restrictions) that has a default value. The generated enum does not seem to have a default constructor, yet the generated default initialization method tries to use the default constructor. I am using xsd 4.0.0 on Windows. Here is a simplified schema that shows the problem: The command-line: xsd cxx-tree schema.xsd Generated code has the following method: static ValueType::colour_type _xsd_ValueTypecolour_default_value_init () { ValueType::colour_type r;//< This uses the default constructor and results in a compilation error. { ::xml_schema::nmtoken tmp ("red"); r.push_back (tmp); } return r; }; Yet, the generated colour_type does not have a default constructor: colour (const ::xml_schema::nmtokens& v); I ran into this particular problem when trying to generate OGC's OWS 1.1.0 schema, see the rangeClosure attribute of RangeType: http://schemas.opengis.net/ows/1.1.0/owsDomainType.xsd Thoughts? Andr? From boris at codesynthesis.com Fri Jan 9 04:43:49 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 9 04:52:42 2015 Subject: [xsd-users] Restricted NMTOKENS (enumeration) with default value In-Reply-To: <54AE960C.4030303@caris.com> References: <54AE960C.4030303@caris.com> Message-ID: Hi Andre, Andre Vautour writes: > I ran into a problem with a schema that has an enumeration > (xsd:NMTOKENS with restrictions) that has a default value. The > generated enum does not seem to have a default constructor, yet the > generated default initialization method tries to use the default > constructor. I have a fix in the repository and can build you a pre-release binary if you would like. An easy workaround is to add the --generate-default-ctor option or change NMTOKENS to NMTOKEN (see below). > > > > > > > > [...] > > I ran into this particular problem when trying to generate OGC's OWS > 1.1.0 schema, see the rangeClosure attribute of RangeType: > http://schemas.opengis.net/ows/1.1.0/owsDomainType.xsd Using NMTOKENS for this enumeration doesn't make any sense. Why would you base a color type on a list of tokens? In fact I suspect what happened is this: someone was editing this schema in some visual editor and when selecting the attribute's type from the drop-down list, accidentally clicked on NMTOKENS instead of NMTOKEN (they would be right next to each other). The result doesn't make sense but is legal XML Schema (as are a lot of other bizarre cases), so nobody noticed. Boris From andre.vautour at caris.com Fri Jan 9 08:04:23 2015 From: andre.vautour at caris.com (Andre Vautour) Date: Fri Jan 9 08:04:31 2015 Subject: [xsd-users] Restricted NMTOKENS (enumeration) with default value In-Reply-To: References: <54AE960C.4030303@caris.com> Message-ID: <54AFD1D7.2020609@caris.com> Thanks Boris. > I have a fix in the repository and can build you a pre-release binary if > you would like. An easy workaround is to add the --generate-default-ctor > option or change NMTOKENS to NMTOKEN (see below). Generating the default constructors for that schema should be fine. I hadn't noticed that option. Cheers, Andr? On 2015-01-09 05:43, Boris Kolpackov wrote: > Hi Andre, > > Andre Vautour writes: > >> I ran into a problem with a schema that has an enumeration >> (xsd:NMTOKENS with restrictions) that has a default value. The >> generated enum does not seem to have a default constructor, yet the >> generated default initialization method tries to use the default >> constructor. > I have a fix in the repository and can build you a pre-release binary if > you would like. An easy workaround is to add the --generate-default-ctor > option or change NMTOKENS to NMTOKEN (see below). > > >> >> >> >> >> >> >> >> [...] >> >> I ran into this particular problem when trying to generate OGC's OWS >> 1.1.0 schema, see the rangeClosure attribute of RangeType: >> http://schemas.opengis.net/ows/1.1.0/owsDomainType.xsd > Using NMTOKENS for this enumeration doesn't make any sense. Why would > you base a color type on a list of tokens? In fact I suspect what > happened is this: someone was editing this schema in some visual > editor and when selecting the attribute's type from the drop-down > list, accidentally clicked on NMTOKENS instead of NMTOKEN (they would > be right next to each other). The result doesn't make sense but is > legal XML Schema (as are a lot of other bizarre cases), so nobody > noticed. > > Boris -- *Andr? Vautour*, B.Sc. Application Developer CARIS 115 Waggoners Lane Fredericton, New Brunswick Canada E3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com *Connect with CARIS* Twitter LinkedIn FaceBook YouTube Download your free copy of CARIS Easy View today! www.caris.com/easyview _________________________________________________________________________ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. From andre.vautour at caris.com Wed Jan 14 15:38:30 2015 From: andre.vautour at caris.com (Andre Vautour) Date: Wed Jan 14 15:38:38 2015 Subject: [xsd-users] Specifying Element content for "anyType" Elements Message-ID: <54B6D3C6.9070704@caris.com> Hi Boris, I wasn't sure if I should start a new thread or not. Since this old thread was basically the same problem I ran into, I (hopefully correctly) decided continuing this old thread was the best way to proceed. The thread's archive link is the following: http://www.codesynthesis.com/pipermail/xsd-users/2008-September/001930.html It had to do with element references to elements that can be substituted, specifically to the naming of those elements in the resulting serialized document. >> i tried to create an PropertyIsEqualTo element which is defined as follows: >> >> > type="ogc:BinaryComparisonOpType" >> substitutionGroup="ogc:comparisonOps"/> >> [...] >> As you can see, the generated element is not the desired one but >> "PropertyIsGreaterThanOrEqualTo". >> >> This element is defined like the PropertyIsEqualTo element: >> >> > type="ogc:BinaryComparisonOpType" substitutionGroup="ogc:comparisonOps"/> >> >> Because they are both of the same type no other class as >> ogc:BinaryComparisonOpType is generated. > > It looks like this schema is using element names as some sort of > identifiers even though they are all of the same type. This does > not work very well with XSD's automatic handling of substitution > groups since the generated code uses the first element name that > matches the type. I see two ways how you can resolve this: > > 1. You can change the schema to an equivalent one but which assigns > different types to different operation elements. This schema will > be equivalent to the original in the sense that it will define > the same XML vocabulary: > > > > > > > > type="ogc:IsEqualToType" > substitutionGroup="ogc:comparisonOps"/> > > > > > > > > type="ogc:IsGreaterThanOrEqualToType" > substitutionGroup="ogc:comparisonOps"/> > > And so on for all the elements that substitute comparisonOps and are > of the BinaryComparisonOpType type. I agree that using inheritance instead of substitutions in this schema would have been more explicit as well as more simple for code generation purposes. Unfortunately, modifying the schema is out of my control. The schema is used to generate code not only in C++, but also in other languages like using JAXB for Java, so modifying it to accommodate a limitation of one of the tools is a hard sell. Keep in mind that you'd have to do that suggested modification for all of the comparisonOps, spatialOps, temporalOps and logicOps of filter.xsd, for each version of the standard: http://schemas.opengis.net/filter/1.0.0/filter.xsd http://schemas.opengis.net/filter/1.1.0/filter.xsd http://schemas.opengis.net/filter/2.0/filter.xsd Also, looking at other OGC and ISO schema files I expect to want to generate in the future, I see lots of element references with possible substitutions, so I expect several of them would also need to be modified. > 2. The second method is quite a bit more involved but does not require > any schema modifications. With this method you will need to customize > all the types that contain the comparisonOps element (e.g., FilterType). > Your customization will need to do two things: > > a) Add a mechanism for specifying which element name should be used. > This can be a modifier function that passes element name as a > string. > > b) Customize the serialization operator to change the name of the > DOM element. This solution, like you said, is quite a bit involved. In addition, having to set the child's name on the parent really doesn't make sense to me. I expect it would also cause confusion to people using the generated classes as they would not know that they need to set the name. It also only seems to address serialization where I also need to parse such documents and the child element name is important to correctly interpret the document. I'm certainly not ruling out customizations as a potential solution, but I would rather one that is more hidden from code that uses the generated code. Did you consider supporting/doing something similar to what JAXB does in this situation? As described in http://stackoverflow.com/a/3659338, in cases where such a substitution group is used, the generated code takes in a JAXBElement (equivalent to element_type) instead of the type object directly. Calling code can then get/set the name on that intermediate object: http://docs.oracle.com/javaee/5/api/javax/xml/bind/JAXBElement.html Kind Regards, Andr? From boris at codesynthesis.com Thu Jan 15 10:10:39 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 15 10:19:30 2015 Subject: [xsd-users] Specifying Element content for "anyType" Elements In-Reply-To: <54B6D3C6.9070704@caris.com> References: <54B6D3C6.9070704@caris.com> Message-ID: Hi Andre, Andre Vautour writes: > Did you consider supporting/doing something similar to what JAXB > does in this situation? [...] No, there are no plans. There is actually a better solution to this problem that I came up with later which is pretty similar (if a bit cleaner, IMO) than what you do in JAXB: http://www.codesynthesis.com/pipermail/xsd-users/2009-August/002411.html Boris From andre.vautour at caris.com Thu Jan 15 13:19:27 2015 From: andre.vautour at caris.com (Andre Vautour) Date: Thu Jan 15 13:19:35 2015 Subject: [xsd-users] Specifying Element content for "anyType" Elements In-Reply-To: References: <54B6D3C6.9070704@caris.com> Message-ID: <54B804AF.4060204@caris.com> Thanks, that solution looks much more appealing to me. That being said, I am having difficulties getting that solution to work in conjunction with the --export-xml-schema option. What ends up happening is that the templates (e.g. simple_type) get instantiated before the epilogue, which means the template instantiation doesn't know the definition of the type class. Any suggestions to work around that problem? I suppose I could always remove the --export-xml-schema option and explicitly add the generated template instantiations to the xml-schema-custom.hxx file. Andr? On 2015-01-15 11:10, Boris Kolpackov wrote: > Hi Andre, > > Andre Vautour writes: > >> Did you consider supporting/doing something similar to what JAXB >> does in this situation? [...] > No, there are no plans. There is actually a better solution to > this problem that I came up with later which is pretty similar > (if a bit cleaner, IMO) than what you do in JAXB: > > http://www.codesynthesis.com/pipermail/xsd-users/2009-August/002411.html > > Boris -- *Andr? Vautour*, B.Sc. Application Developer CARIS 115 Waggoners Lane Fredericton, New Brunswick Canada E3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 www.caris.com *Connect with CARIS* Twitter LinkedIn FaceBook YouTube Download your free copy of CARIS Easy View today! www.caris.com/easyview _________________________________________________________________________ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. From boris at codesynthesis.com Fri Jan 16 08:40:53 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 16 08:49:44 2015 Subject: [xsd-users] Specifying Element content for "anyType" Elements In-Reply-To: <54B804AF.4060204@caris.com> References: <54B6D3C6.9070704@caris.com> <54B804AF.4060204@caris.com> Message-ID: Hi Andre, Andre Vautour writes: > What ends up happening is that the templates (e.g. simple_type) get > instantiated before the epilogue, which means the template > instantiation doesn't know the definition of the type class. Yes, that's an unfortunate interaction of several things. > Any suggestions to work around that problem? The way to make this work is to include the header in prologue, not epilogue. You will also have to get rid of type_base and instead include necessary headers from libxsd directly () and also derive from xsd::cxx::tree::type instead of type_base. Boris From Joseph.Gagnon at ll.mit.edu Fri Jan 16 12:43:31 2015 From: Joseph.Gagnon at ll.mit.edu (Gagnon, Joseph - 0558 - MITLL) Date: Fri Jan 16 12:43:39 2015 Subject: [xsd-users] Namespace mapping problem Message-ID: I just downloaded XSD for evaluation. When I tried to generate a C++ API from a schema, I received the following error message: xsd.exe cxx-tree --root-element-all C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControlled.xs d C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControlled.xs d:3:268: error: unable to map XML Schema nam espace 'http://some-oms-website.mil/' to C++ namespace C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControlled.xs d:3:268: info: use the --namespace-map or -- namespace-regex option to provide custom mapping I tried using the -namespace-map and -namespace-regex options but was unable to make any progress. I then grabbed another schema file related to the first and tried running XSD on it. I got the same error, but on a different namespace. It appears that URI specified as the target namespace is what is being complained about. Both of these schema files have multiple namespace declarations (i.e. xmlns:XXX="some URI") I cannot figure out what is wrong or what I need to do to correct the problem. I'm not sure if I used the --namespace* options correctly, although the --namespace-map option seemed pretty straightforward. As a side note, I had originally run XSD with no options, but got the error: C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControlled.xs d: warning T004: generating parsing function s for 13 global elements C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControlled.xs d: info: use --root-element-* options to spe cify document root(s) I'm not sure what 13 global elements it was referring to, but decided to add the --root-element-all option. Any ideas on what could be wrong? Thanks, Joe Gagnon Engineer II Group 58 - Cyber Systems & Technology MIT Lincoln Laboratory Lexington, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5625 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20150116/9f7905ed/smime.bin From boris at codesynthesis.com Mon Jan 19 08:22:30 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 19 08:31:19 2015 Subject: [xsd-users] Namespace mapping problem In-Reply-To: References: Message-ID: Hi Joseph, Gagnon, Joseph - 0558 - MITLL writes: > I tried using the -namespace-map and -namespace-regex options but was unable > to make any progress. > > [...] > > I cannot figure out what is wrong or what I need to do to correct the > problem. I'm not sure if I used the --namespace* options correctly, > although the --namespace-map option seemed pretty straightforward. Since you haven't provided any concrete information on what you have tried and what exactly doesn't work, I can only say that the --namespace-map option has the following general usage: --namespace-map http://some-oms-website.mil/=SomeCppNamespace It is indeed very hard to misuse. > As a side note, I had originally run XSD with no options, but got the error: > > C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControlled.xs > d: warning T004: generating parsing functions for 13 global elements > > C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControlled.xs > d: info: use --root-element-* options to specify document root(s) This is not an error. It is a warning. > I'm not sure what 13 global elements it was referring to, but decided to add > the --root-element-all option. In XML Schema every global element is a valid document root element. But global elements are also often used for other things (e.g., to 'ref' in multiple places or for substitution groups). At the same time there is normally (but not always) only one actual document root. As a result, when your schema has multiple global elements, XSD will assume that all of them are valid root elements and generate a set of parsing/serialization functions for each of them. Since this is normally wasteful (code bloat), XSD issues this warning. Boris From Joseph.Gagnon at ll.mit.edu Tue Jan 20 09:21:21 2015 From: Joseph.Gagnon at ll.mit.edu (Gagnon, Joseph - 0558 - MITLL) Date: Tue Jan 20 09:21:33 2015 Subject: [xsd-users] Namespace mapping problem In-Reply-To: References: Message-ID: Boris, I think the problem is associated with the fact that the targetNamespace attribute in the XSD is not a "real" URI. As an example, when I run a simple test schema like the following: ... I get the following from XSD: PS C:\Users\jo24447> C:\Users\jo24447\Downloads\xsd-4.0.0-i686-windows\bin\xsd cxx-tree C:\Users\jo24447\ServiceContract_Message.xsd C:\Users\jo24447\ServiceContract_Message.xsd:2:166: error: unable to map XML Schema namespace 'http://www.somesite.org/' to C++ namespace C:\Users\jo24447\ServiceContract_Message.xsd:2:166: info: use the --namespace-map or --namespace-regex option to provide custom mapping If I change the target to something I know is a valid existing URL (e.g. http://www.google.com) the error above no longer occurs (although I do get other errors that appear to be related). To be honest, I don't really understand the purpose or behavior of the targetNamespace attribute or what requirements must be met when it's specified and what it is used for when a schema is compiled or parsed. After some more experimentation I was able to get my simple schema to be successfully processed by XSD (see below). For this to happen, I needed to remove the namespace specifier and the targetNamespace attributes. The schema is fully self-contained anyway (and as I mentioned earlier, I don't understand the namespace attributes very well). This time XSD runs without error and produces a single .hxx and .cxx file, each named after the schema file name (I was expecting different types to be broken out into separate files). So, success at last. However, this does not solve a larger issue for me that is probably due to the way the "real" schema I'm using is constructed. A little background: I have no control over the schema. It is owned by another organization. It does consist of multiple XSD files. It has a similar situation to what I described for my simple test case above in that the targetNamespace URI does not exist (at least not as far as I am able to determine). Unfortunately I am not at liberty to provide any other information about the schema to you. I realize this is probably not very helpful, but I have no choice in the matter. If you have any suggestions, insights or general knowledge to impart, please feel free to do so. Thanks, Joe Gagnon -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, January 19, 2015 8:23 AM To: Gagnon, Joseph - 0558 - MITLL Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Namespace mapping problem Hi Joseph, Gagnon, Joseph - 0558 - MITLL writes: > I tried using the -namespace-map and -namespace-regex options but was > unable to make any progress. > > [...] > > I cannot figure out what is wrong or what I need to do to correct the > problem. I'm not sure if I used the --namespace* options correctly, > although the --namespace-map option seemed pretty straightforward. Since you haven't provided any concrete information on what you have tried and what exactly doesn't work, I can only say that the --namespace-map option has the following general usage: --namespace-map http://some-oms-website.mil/=SomeCppNamespace It is indeed very hard to misuse. > As a side note, I had originally run XSD with no options, but got the error: > > C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControl > led.xs > d: warning T004: generating parsing functions for 13 global elements > > C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControl > led.xs > d: info: use --root-element-* options to specify document root(s) This is not an error. It is a warning. > I'm not sure what 13 global elements it was referring to, but decided > to add the --root-element-all option. In XML Schema every global element is a valid document root element. But global elements are also often used for other things (e.g., to 'ref' in multiple places or for substitution groups). At the same time there is normally (but not always) only one actual document root. As a result, when your schema has multiple global elements, XSD will assume that all of them are valid root elements and generate a set of parsing/serialization functions for each of them. Since this is normally wasteful (code bloat), XSD issues this warning. Boris -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5625 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20150120/6aa0ec26/smime.bin From andre.vautour at caris.com Tue Jan 20 10:48:12 2015 From: andre.vautour at caris.com (Andre Vautour) Date: Tue Jan 20 10:48:20 2015 Subject: [xsd-users] Namespace mapping problem In-Reply-To: References: Message-ID: <54BE78BC.8050405@caris.com> Hi Joe, See my comments inline. Also, please note that, unlike Boris, I am simply a user of the tool. Cheers, Andr? On 2015-01-20 10:21, Gagnon, Joseph - 0558 - MITLL wrote: > Boris, > > I think the problem is associated with the fact that the targetNamespace > attribute in the XSD is not a "real" URI. As an example, when I run a simple > test schema like the following: > > > xmlns:sc="http://www.somesite.org/" targetNamespace="http://www.somesite.org/" > elementFormDefault="qualified"> > > ... > > > I get the following from XSD: > > PS C:\Users\jo24447> C:\Users\jo24447\Downloads\xsd-4.0.0-i686-windows\bin\xsd > cxx-tree C:\Users\jo24447\ServiceContract_Message.xsd > C:\Users\jo24447\ServiceContract_Message.xsd:2:166: error: unable to map XML > Schema namespace 'http://www.somesite.org/' to C++ namespace > C:\Users\jo24447\ServiceContract_Message.xsd:2:166: info: use > the --namespace-map or --namespace-regex option to provide custom mapping > > If I change the target to something I know is a valid existing URL (e.g. > http://www.google.com) the error above no longer occurs (although I do get > other errors that appear to be related). > > To be honest, I don't really understand the purpose or behavior of the > targetNamespace attribute or what requirements must be met when it's specified > and what it is used for when a schema is compiled or parsed. In XML, namespaces are simply used as a mechanism for scoping names to avoid duplicate names when using elements from multiple different schemas. While it is common for a namespace name to be a URI, the W3C doesn't even mandate it to be a URI, so, it certainly doesn't need to be a URL that exists and is valid. Using a URI simply increases the chances that the namespace name will be unique. Since the namespaces are used in XML to avoid duplicate names, it stands to reason that the generated code needs to maintain that scoping, else it could result it duplicate types in the generate code. I believe that the default behaviour of the tool is to maintain the namespace name of the XML schema, but it can only do so if the namespace name is also a valid C++ namespace name. When it isn't, the tool needs information to know how to map the XML namespace name to a valid C++ namespace. In your example, with namespace http://some-oms-website.mil/, the tool would have generated the following code which isn't valid C++: namespace http://some-oms-website.mil/ { class ... {}; } With the mapping suggested by Boris (--namespace-map http://some-oms-website.mil/=SomeCppNamespace), it would instead generate: namespace SomeCppNamespace { class ... {}; } So, the namespace mapping option basically says, for each element/type in a XML namespace, generate the associated C++ classes in a C++ namespace with a given name. > After some more experimentation I was able to get my simple schema to be > successfully processed by XSD (see below). For this to happen, I needed to > remove the namespace specifier and the targetNamespace attributes. The schema > is fully self-contained anyway (and as I mentioned earlier, I don't understand > the namespace attributes very well). > > elementFormDefault="qualified"> > > This time XSD runs without error and produces a single .hxx and .cxx file, > each named after the schema file name (I was expecting different types to be > broken out into separate files). See the --file-per-type option. > So, success at last. However, this does not solve a larger issue for me that > is probably due to the way the "real" schema I'm using is constructed. A > little background: I have no control over the schema. It is owned by another > organization. It does consist of multiple XSD files. It has a similar > situation to what I described for my simple test case above in that the > targetNamespace URI does not exist (at least not as far as I am able to > determine). Unfortunately I am not at liberty to provide any other information > about the schema to you. As Boris had mentioned in his reply, I believe the most helpful piece of information would be to provide the namespace mapping options that you tried on the original, unmodified schema. I believe you said you tried using the --namespace-map option. Could you provide the exact command-line options that you tried that did not work? Are you sure you used the same namespace URI (case, trailing slash, etc.)? While you might not be able to provide the original schema, could you instead provide a test schema that reproduces the issue you have encountered? > > I realize this is probably not very helpful, but I have no choice in the > matter. If you have any suggestions, insights or general knowledge to impart, > please feel free to do so. > > Thanks, > Joe Gagnon > > > -----Original Message----- > From: Boris Kolpackov [mailto:boris@codesynthesis.com] > Sent: Monday, January 19, 2015 8:23 AM > To: Gagnon, Joseph - 0558 - MITLL > Cc: xsd-users@codesynthesis.com > Subject: Re: [xsd-users] Namespace mapping problem > > Hi Joseph, > > Gagnon, Joseph - 0558 - MITLL writes: > >> I tried using the -namespace-map and -namespace-regex options but was >> unable to make any progress. >> >> [...] >> >> I cannot figure out what is wrong or what I need to do to correct the >> problem. I'm not sure if I used the --namespace* options correctly, >> although the --namespace-map option seemed pretty straightforward. > Since you haven't provided any concrete information on what you have tried and > what exactly doesn't work, I can only say that the --namespace-map option has > the following general usage: > > --namespace-map http://some-oms-website.mil/=SomeCppNamespace > > It is indeed very hard to misuse. > > >> As a side note, I had originally run XSD with no options, but got the error: >> >> C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControl >> led.xs >> d: warning T004: generating parsing functions for 13 global elements >> >> C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControl >> led.xs >> d: info: use --root-element-* options to specify document root(s) > This is not an error. It is a warning. > > >> I'm not sure what 13 global elements it was referring to, but decided >> to add the --root-element-all option. > In XML Schema every global element is a valid document root element. > But global elements are also often used for other things (e.g., to 'ref' in > multiple places or for substitution groups). At the same time there is > normally (but not always) only one actual document root. As a result, when > your schema has multiple global elements, XSD will assume that all of them are > valid root elements and generate a set of parsing/serialization functions for > each of them. Since this is normally wasteful (code bloat), XSD issues this > warning. > > Boris From boris at codesynthesis.com Tue Jan 20 10:43:31 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jan 20 10:52:21 2015 Subject: [xsd-users] Namespace mapping problem In-Reply-To: References: Message-ID: <20150120154331.GA4384@codesynthesis.com> Hi Joseph, Gagnon, Joseph - 0558 - MITLL writes: > I get the following from XSD: > > PS C:\Users\jo24447> C:\Users\jo24447\Downloads\xsd-4.0.0-i686-windows\bin\xsd > cxx-tree C:\Users\jo24447\ServiceContract_Message.xsd > C:\Users\jo24447\ServiceContract_Message.xsd:2:166: error: unable to map XML > Schema namespace 'http://www.somesite.org/' to C++ namespace > C:\Users\jo24447\ServiceContract_Message.xsd:2:166: info: use > the --namespace-map or --namespace-regex option to provide custom mapping > > If I change the target to something I know is a valid existing URL (e.g. > http://www.google.com) the error above no longer occurs (although I do get > other errors that appear to be related). The targetNamespace attribute can contain anything. It doesn't have to be a URL. Quite a few schemas use the foo:bar:baz format. XSD tries to automatically map some commonly-used formats (e.g., URL with some path after the host name, etc) to C++ namespaces but it cannot always do this. When it can't it issues the above error. But, and that's what baffles me about your situation, it is extremely easy to resolve with the --namespace-map option, as helpfully suggested by the error message. Simply adding: --namespace-map http://www.somesite.org/=SomeCxxNamespace to the command line should solve this problem. If that doesn't work for you for some reason, please send detailed description of how exactly it doesn't work (e.g., error messages, generated code looks wrong, etc). > I was expecting different types to be broken out into separate files You can get this behavior with the --file-per-type option though unless you really have to use this mode, it is not recommended. See this post for details: http://www.codesynthesis.com/~boris/blog/2008/02/13/codesynthesis-xsd-3-1-0-released/ Boris From albert.babinskas at imagingsciences.com Thu Jan 22 07:31:43 2015 From: albert.babinskas at imagingsciences.com (Babinskas, Albert) Date: Thu Jan 22 07:31:52 2015 Subject: [xsd-users] Missing a parsing function Message-ID: <159da384199f4315908149c8906bcba0@DENORASPEXCH2.sds.sybrondental.com> HI, I Have this Schema: I don't have type for reference_t I can create reference_t by writing: reference_t ref; ref.id() = "someID"; ref.href() = "someHref"; But my problem is I don't have a function to serialize reference_t. I don't have this: ::reference(ref) These are the settings I am compiling my schema with: xsd.exe cxx-tree --char-type char --char-encoding utf8 --generate-serialization --generate-ostream --generate-default-ctor --generate-wildcard --generate-polymorphic --namespace-map http://api.ditcdev.com/schema/datawarehouse/v1.3.0-130=schema::datawarehouse schema1.xsd What setting I need to set to compile my Schema, to get serialization function for reference_t? -Albert From boris at codesynthesis.com Thu Jan 22 08:35:26 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 22 08:44:15 2015 Subject: [xsd-users] Missing a parsing function In-Reply-To: <159da384199f4315908149c8906bcba0@DENORASPEXCH2.sds.sybrondental.com> References: <159da384199f4315908149c8906bcba0@DENORASPEXCH2.sds.sybrondental.com> Message-ID: Hi Albert, Babinskas, Albert writes: > But my problem is I don't have a function to serialize reference_t. > I don't have this: > ::reference(ref) The easiest way would be to define the 'reference' element and let XSD generate the code for you. If you don't want to modify the schema, you can create a separate one on the side that includes the original and only defines the global element(s). If you don't want to go this route, then you will need to create the empty DOM document yourself, call the serialization operator of reference_t, and then save the DOM document to XML (yes, quite a bit more work than above but could be better if you have, say, hundreds of such types). The 'messaging' example is probably the closest to what you would want. In particular, it has the serialize() function that saves DOM to XML, so you can just take that. The part that will be different is this line in driver.cxx: xml_schema::element_map::serialize (*doc->getDocumentElement (), *res); In your case you will have something like: reference_t& ref = ... *doc->getDocumentElement () << ref; Boris