From boris at codesynthesis.com Tue Dec 1 08:55:44 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 1 08:55:43 2015 Subject: [xsd-users] xsd build errors on BeagleBone Black with Kali Linux 2.0 In-Reply-To: References: Message-ID: Hi Arthur, Arthur Lobo writes: > /root/Downloads/xsd-3.3.0+dep/xsd/xsd/xsd.hxx:41:26: error: ?XSDFrontend::SemanticGraph::Path? has no member named ?native_file_string? > std::remove (file_.native_file_string ().c_str ()); Try xsd-3.3.0-2+dep.tar.bz2 (notice '-2') instead. Boris From jon.k.winn at rrd.com Wed Dec 2 09:22:53 2015 From: jon.k.winn at rrd.com (Jon Winn) Date: Wed Dec 2 09:23:20 2015 Subject: [xsd-users] Handling of complex restrictions on types Message-ID: RE: http://codesynthesis.com/pipermail/xsd-users/2015-March/004564.html I'm trying to remedy the same problem that Yury brings up here. Namely: >Ideally, I would like to have all of them checked at runtime, so that the >constructors and/or setters would raise an exception when the restrictions >are not adhered to. In the thread Boris states: >Yes, all valid points. Unfortunately, implementing restriction >validation in the generated code if probably an order of magnitude >larger amount of work. And at this stage we have to plans to >do it. Is it still the case that XSD does not and will not have runtime validation in the near future? I face the same dilemma. This feature would benefit our application greatly! JKW From boris at codesynthesis.com Thu Dec 3 09:17:31 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 3 09:17:32 2015 Subject: [xsd-users] Handling of complex restrictions on types In-Reply-To: References: Message-ID: Hi Jon, Jon Winn writes: > Is it still the case that XSD does not and will not have runtime validation > in the near future? That's still correct. > I face the same dilemma. This feature would benefit our application greatly! I've spent a fair amount of time in the past years thinking about this problem and the way I see it, it can be done in two different ways: 1. I "straightforward" implementation that will be pretty much unusable (as in "minOccurs says 1 and size is 0 -- throw; who cares the user hasn't had a chance to insert anything yet). 2. A more "thoughtful" implementation that will be some complex (and thus buggy) as to be unusable as well. So I believe that in the "real world", the only approach that has a realistic chance of working is to enforce as much of the schema as possible via the static interface (so that an invalid instance is impossible to make in the first place; a constructor with all the non-optional members is a good example of this). And as for the rest, the user will just have to be careful enough (and keep it simple), just like in the rest of programming. Boris From kent.bair at directfinancialsolutions.com Sun Dec 6 03:38:14 2015 From: kent.bair at directfinancialsolutions.com (Kent Bair) Date: Mon Dec 7 08:02:49 2015 Subject: [xsd-users] MS Visual Studio 2015 Message-ID: Do you have plans for supporting MS Visual Studio 2015 in the near future? Kent Bair Direct Financial Solutions Software Developer From boris at codesynthesis.com Mon Dec 7 08:08:19 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 7 08:08:23 2015 Subject: [xsd-users] MS Visual Studio 2015 In-Reply-To: References: Message-ID: Hi Kent, Kent Bair writes: > Do you have plans for supporting MS Visual Studio 2015 in the near future? Yes, it will be "officially" supported with the next release. Note, however, that nothing prevents you from using the current version with VS2015. Quite a few people already do and there no issues. Boris From amnw14545 at googlemail.com Thu Dec 10 05:44:39 2015 From: amnw14545 at googlemail.com (Tony McConnell) Date: Thu Dec 10 07:10:11 2015 Subject: [xsd-users] Default values of elements that use enumerated types Message-ID: Hello, I'm using xsd amd64 4.0.0-1 debian package on Ubuntu 14.04 with xerces-c 3.1.1-5.1 I'm using the following to generate code for parsing and serialising: xsdcxx cxx-tree --hxx-suffix .h --cxx-suffix .cc --reserved-name xml_schema=datex2api_xml_schema --generate-serialization --proprietary-license --generate-polymorphic --polymorphic-type-all --disable-warning all --extern-xml-schema datex2_common.h --polymorphic-plate 1 \ --namespace-map http://datex2.eu/schema/2_0RC2/2_0=datex2_0RC2_2_0 /tmp/DATEXIISchema_2_0RC2_2_0.xsd The schema contains an enumerated type, PrecipitationType, based on xsd:string and an element, precipitation, that uses that type. but which also has a default value of 'drizzle'. '' When I create some XML that has 'drizzle', xmllint and the generated parsing code are happy with it. When I create some XML that has '', xmllint is happy, but the generated code produces an 'unexpected enumeration' exception. Should XSD support default element values, or is this some problem with the underlying xerces-c parser? Cheers Tony McConnell From amnw14545 at googlemail.com Thu Dec 10 06:37:43 2015 From: amnw14545 at googlemail.com (Tony McConnell) Date: Thu Dec 10 07:10:11 2015 Subject: [xsd-users] Re: Default values of elements that use enumerated types In-Reply-To: References: Message-ID: Unfortunately, the exception seems to arise from the xerces-c parser. Bugger. On Thu, Dec 10, 2015 at 10:44 AM, Tony McConnell wrote: > Hello, > > I'm using xsd amd64 4.0.0-1 debian package on Ubuntu 14.04 with xerces-c > 3.1.1-5.1 > > I'm using the following to generate code for parsing and serialising: > > xsdcxx cxx-tree --hxx-suffix .h --cxx-suffix .cc --reserved-name > xml_schema=datex2api_xml_schema --generate-serialization > --proprietary-license --generate-polymorphic --polymorphic-type-all > --disable-warning all --extern-xml-schema datex2_common.h > --polymorphic-plate 1 \ > --namespace-map > http://datex2.eu/schema/2_0RC2/2_0=datex2_0RC2_2_0 > /tmp/DATEXIISchema_2_0RC2_2_0.xsd > > The schema contains an enumerated type, PrecipitationType, based on > xsd:string and an element, precipitation, that uses that type. but which > also has a default value of 'drizzle'. > > '' > > When I create some XML that has 'drizzle', > xmllint and the generated parsing code are happy with it. > > When I create some XML that has '', xmllint > is happy, but the generated code produces an 'unexpected enumeration' > exception. > > Should XSD support default element values, or is this some problem with > the underlying xerces-c parser? > > Cheers > > Tony McConnell > > From amnw14545 at googlemail.com Thu Dec 10 07:25:36 2015 From: amnw14545 at googlemail.com (Tony McConnell) Date: Thu Dec 10 07:33:32 2015 Subject: [xsd-users] Re: Default values of elements that use enumerated types In-Reply-To: References: Message-ID: And xerces-c-3.1.2 suffers from the same problem. Cannot validate the schema against valid xml. Can't use expat as using cxx-tree... On Thu, Dec 10, 2015 at 11:37 AM, Tony McConnell wrote: > Unfortunately, the exception seems to arise from the xerces-c parser. > Bugger. > > > On Thu, Dec 10, 2015 at 10:44 AM, Tony McConnell > wrote: > >> Hello, >> >> I'm using xsd amd64 4.0.0-1 debian package on Ubuntu 14.04 with xerces-c >> 3.1.1-5.1 >> >> I'm using the following to generate code for parsing and serialising: >> >> xsdcxx cxx-tree --hxx-suffix .h --cxx-suffix .cc --reserved-name >> xml_schema=datex2api_xml_schema --generate-serialization >> --proprietary-license --generate-polymorphic --polymorphic-type-all >> --disable-warning all --extern-xml-schema datex2_common.h >> --polymorphic-plate 1 \ >> --namespace-map >> http://datex2.eu/schema/2_0RC2/2_0=datex2_0RC2_2_0 >> /tmp/DATEXIISchema_2_0RC2_2_0.xsd >> >> The schema contains an enumerated type, PrecipitationType, based on >> xsd:string and an element, precipitation, that uses that type. but which >> also has a default value of 'drizzle'. >> >> '> default="drizzle">' >> >> When I create some XML that has 'drizzle', >> xmllint and the generated parsing code are happy with it. >> >> When I create some XML that has '', >> xmllint is happy, but the generated code produces an 'unexpected >> enumeration' exception. >> >> Should XSD support default element values, or is this some problem with >> the underlying xerces-c parser? >> >> Cheers >> >> Tony McConnell >> >> > From boris at codesynthesis.com Thu Dec 10 08:37:49 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 10 08:37:50 2015 Subject: [xsd-users] Default values of elements that use enumerated types In-Reply-To: References: Message-ID: Hi Tony, Tony McConnell writes: > When I create some XML that has '', xmllint > is happy, but the generated code produces an 'unexpected enumeration' > exception. > > Should XSD support default element values, or is this some problem with the > underlying xerces-c parser? This should work, provided you did not disable validation at the Xerces-C++ level (since, unlike for attributes with default values, for elements XSD- generated code relies on the underlying parser to "expand" the default values). What is the exact error that you are getting and what do you do to parse this XML (i.e., show the relevant C++ fragment)? Boris From amnw14545 at googlemail.com Thu Dec 10 09:08:15 2015 From: amnw14545 at googlemail.com (Tony McConnell) Date: Thu Dec 10 09:27:53 2015 Subject: [xsd-users] Default values of elements that use enumerated types In-Reply-To: References: Message-ID: Thank you for your prompt reply. I've enclosed a small test case as this is where I think the problem lies. xmllint is able to validate the t.xml against t.xsd Yet passing the files into the xerces-c validator (t.cc) gives the same type of exception I get from my xsd generated parsing code - leading me to suspect it is not XSD at fault, but xerces-c. Should libxerces-c be able to validate this? Thank you Tony On Thu, Dec 10, 2015 at 1:37 PM, Boris Kolpackov wrote: > Hi Tony, > > Tony McConnell writes: > > > When I create some XML that has '', > xmllint > > is happy, but the generated code produces an 'unexpected enumeration' > > exception. > > > > Should XSD support default element values, or is this some problem with > the > > underlying xerces-c parser? > > This should work, provided you did not disable validation at the Xerces-C++ > level (since, unlike for attributes with default values, for elements XSD- > generated code relies on the underlying parser to "expand" the default > values). What is the exact error that you are getting and what do you do > to parse this XML (i.e., show the relevant C++ fragment)? > > Boris > -------------- next part -------------- A non-text attachment was scrubbed... Name: tc.tgz Type: application/x-gzip Size: 27448 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20151210/e591365c/tc-0001.bin From boris at codesynthesis.com Thu Dec 10 09:49:57 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 10 09:49:59 2015 Subject: [xsd-users] Default values of elements that use enumerated types In-Reply-To: References: Message-ID: Hi Tony, Tony McConnell writes: > I've enclosed a small test case as this is where I think the problem lies. Something is wrong with the way you setup the parser. Specifically, it downloads the schema from the URL in (schemaLocation) rather than using the local one. If I use my own schema loader/validator, there are no errors. See for details/source code: http://codesynthesis.com/~boris/blog/2010/03/15/validating-external-schemas-xerces-cxx/ Boris From amnw14545 at googlemail.com Thu Dec 10 10:04:37 2015 From: amnw14545 at googlemail.com (Tony McConnell) Date: Fri Dec 11 07:33:00 2015 Subject: [xsd-users] Default values of elements that use enumerated types In-Reply-To: References: Message-ID: Whoops, "one of the recurring questions...", I am sorry about that! On Thu, Dec 10, 2015 at 2:49 PM, Boris Kolpackov wrote: > Hi Tony, > > Tony McConnell writes: > > > I've enclosed a small test case as this is where I think the problem > lies. > > Something is wrong with the way you setup the parser. Specifically, it > downloads the schema from the URL in (schemaLocation) rather than using > the local one. If I use my own schema loader/validator, there are no > errors. See for details/source code: > > > http://codesynthesis.com/~boris/blog/2010/03/15/validating-external-schemas-xerces-cxx/ > > Boris > From aciel.eshky at gmail.com Wed Dec 16 13:14:38 2015 From: aciel.eshky at gmail.com (Aciel Eshky) Date: Thu Dec 17 09:23:27 2015 Subject: [xsd-users] unable to write new fields to XML file Message-ID: Hi there, We're trying to use CodeSynthesis XSD 4.0 in visual studio 2015 as an interface to a fairly complex xml schema. We have successfully compiled the schema and generated the classes, and we're able to read the contents or an xml file and process them. Some of the xml tags in the schema are optional, and specify the results of computations that we carry out on the contents of the input xml file. The input xml file has none of these results fields, but the output xml file should have them. We are able to populate these filed in the c++ object representing the xml file, but when we print the object to a file none of the results fields are printed. Any idea what the issue could be? Thanks. -- Aciel From boris at codesynthesis.com Thu Dec 17 09:34:26 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 17 09:34:22 2015 Subject: [xsd-users] unable to write new fields to XML file In-Reply-To: References: Message-ID: Hi Aciel, Aciel Eshky writes: > Some of the xml tags in the schema are optional, and specify the results of > computations that we carry out on the contents of the input xml file. The > input xml file has none of these results fields, but the output xml file > should have them. We are able to populate these filed in the c++ object > representing the xml file, but when we print the object to a file none of > the results fields are printed. Any idea what the issue could be? My first guess is that you are making copies of the model nodes instaed of using references. As result, when you then modify them, you are modifying copies, not the original object model. See Section 4.3, "Modifying the Object Model" for more details on this issue: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#4.3 Boris From aciel.eshky at gmail.com Mon Dec 28 06:40:27 2015 From: aciel.eshky at gmail.com (Aciel Eshky) Date: Thu Dec 31 01:54:01 2015 Subject: [xsd-users] unable to write new fields to XML file In-Reply-To: References: Message-ID: Hi Boris, Thanks for your response. I was able to resolve the problem by removing the namespace from the xsd file. I am now able to write the results to an output xml file (which looks like the input but with the results appended to it). If possible, I'd still like to understand why it wasn't working properly before. In my xsd options, I was previously using the namespace mapping and it was working properly as far as input xml files are concered. Perhaps I was missing something similar for the output? Here is my c++ code. xml_schema::namespace_infomap map; map[""].name = "ourwebsite"; map[""].schema = "ourschemaname.xsd"; char* ptr_xml_file_out = "output_with_results.xml"; std::ofstream ofs(ptr_xml_file_out); QBAS_(ofs, *q, map); Any useful insights would be appreciated. Thanks! Aciel On 17 December 2015 at 14:34, Boris Kolpackov wrote: > Hi Aciel, > > Aciel Eshky writes: > > > Some of the xml tags in the schema are optional, and specify the results > of > > computations that we carry out on the contents of the input xml file. The > > input xml file has none of these results fields, but the output xml file > > should have them. We are able to populate these filed in the c++ object > > representing the xml file, but when we print the object to a file none of > > the results fields are printed. Any idea what the issue could be? > > My first guess is that you are making copies of the model nodes instaed of > using references. As result, when you then modify them, you are modifying > copies, not the original object model. > > See Section 4.3, "Modifying the Object Model" for more details on this > issue: > > http://codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#4.3 > > Boris > -- Aciel