From boris at codesynthesis.com Mon Mar 1 08:11:05 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 1 08:01:29 2010 Subject: [xsde-users] Re: XSDE Execution Problems under Fedora Linux 64-bit In-Reply-To: <8A69033E02ED29419B0F43AD421CEC3A225055@novaxcg01.csw.l-3com.com> References: <8A69033E02ED29419B0F43AD421CEC3A225050@novaxcg01.csw.l-3com.com> <8A69033E02ED29419B0F43AD421CEC3A225051@novaxcg01.csw.l-3com.com> <8A69033E02ED29419B0F43AD421CEC3A225055@novaxcg01.csw.l-3com.com> Message-ID: Hi Bob, I've CC'ed xsde-users@codesynthesis.com to my reply in case someone else has a similar question one day. Bob.Oneil@L-3Com.com writes: > Hi Boris, is it necessary to build with exceptions enabled if we want to > detect an XML write error > and have some output that describes which particular element failed > validation? Without exceptions, > would you simply examine the return value from a write operation, or > other overload of a virtual > function (such as a post()) that would indicate which particular element > failed validation? With C++ exceptions disabled, the error handling is performed with error codes. For more information on error handling with codes during parsing, see Section 7.3, "Error Codes" in the Embedded C++/Parser Mapping Getting Started Guide: http://www.codesynthesis.com/projects/xsde/documentation/cxx/parser/guide/#7.3 For the same during serialization, see Section 8.3, "Error Codes" in the Embedded C++/Serializer Mapping Getting Started Guide: http://www.codesynthesis.com/projects/xsde/documentation/cxx/serializer/guide/#8.3 Finally, if you modify the C++/Hybrid object model, there could be memory allocation errors. For more information on handling these, see Chapter 4, "Working with Object Models" in the Embedded C++/Hybrid Mapping Getting Started Guide: http://www.codesynthesis.com/projects/xsde/documentation/cxx/hybrid/guide/#4 There is also the 'minimal' example in the examples/cxx/hybrid/ directory of XSD/e distribution that shows how to use error codes for all of the above operations. Boris From boris at codesynthesis.com Mon Mar 1 08:27:43 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 1 08:18:08 2010 Subject: [xsde-users] XSD/e 3.1.0 binary for x86-64 GNU/Linux host available Message-ID: Hi, We have uploaded the XSD/e 3.1.0 binary package for the x86-64 GNU/Linux host development platform. It is primarily useful in cases where your Linux installation is not able to run 32-bit executables, for example, because the 32-bit glibc is not installed. You can download this package from the XSD/e Download page: http://www.codesynthesis.com/products/xsde/download.xhtml The SHA1 checksum for the file: 40f3d2177b337e6a4b02c8fee941cd8741f129e4 xsde-3.1.0-x86_64-linux-gnu.tar.bz2 Boris From boris at codesynthesis.com Fri Mar 12 06:55:07 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 12 06:44:46 2010 Subject: [xsde-users] Re: Modifying C++ Class Wrapper Generated From Parser and Serializing to Persistent File Storage In-Reply-To: <8A69033E02ED29419B0F43AD421CEC3A47D975@novaxcg01.csw.l-3com.com> References: <8A69033E02ED29419B0F43AD421CEC3A47D975@novaxcg01.csw.l-3com.com> Message-ID: Hi Bob, [CC'ed xsde-users] Bob.Oneil@L-3Com.com writes: > Hi Boris, I have both reading and writing working correctly to and from > files with xsde. > > Where I have some remaining questions is what to do in the middle of > these operations, that is changes that are made to the values > represented by the C++mapped class between the read and save. > > During program execution, values can change for existing items in the > C++ class (such as password, numeric quantities, etc.) > > With each change, I need to make changes to the C++ class created > dynamically during the parsing process, and then update the underlying > XML file repository via serialization. > > These changes may result in additional items to those that are > represented as XML sequences, but much more likely, are modifications to > the existing settings for the class rather than new content. > > What is missing from my understanding is how to modify programmatically > the values associated with the underlying xml schema in the C++ class > created as a result of the parsing. > > All of the values at their fundamental low level are private, and I > can't find a direct means of modifying their content (i.e. assignment > overload). The object model provides modifier functions for every member (element, attribute or "base content"). Sometimes these modifiers are inherited from the base class. The relevant parts of the document are Chapter 4, "Working with Object Models", and Chapter 5, "Mapping for Built-In XML Schema Types" in the C++/Hybrid Getting Started Guide: http://www.codesynthesis.com/projects/xsde/documentation/cxx/hybrid/guide/ Boris From Bob.Oneil at L-3Com.com Mon Mar 15 15:20:58 2010 From: Bob.Oneil at L-3Com.com (Bob.Oneil@L-3Com.com) Date: Mon Mar 15 15:21:05 2010 Subject: [xsde-users] Duplicate Class Names Across Multiple XML/XSD Schema Implementations Message-ID: <8A69033E02ED29419B0F43AD421CEC3A47D984@novaxcg01.csw.l-3com.com> It would seem that when combining multiple XSD files not the same project, and building a driver which sequences from reading and validating one XML file followed by another, that when building under Eclipse under 64-bit Linux (and in general other configurations), that the names of the settings in the XSD file should be unique to avoid any type of collisions. For example, if the XSD files contain an element named "Author" in both files, GCC will report collisions on the class names even if the elements are at different leafs of the XSD tree. Perhaps best practices when using multiple XSD file support in the same executable is to specific that unique names should be used in the XSD files to prevent such collisions. Perhaps you have other solutions that would remove this restriction. From boris at codesynthesis.com Mon Mar 15 16:11:06 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 15 16:00:32 2010 Subject: [xsde-users] Duplicate Class Names Across Multiple XML/XSD Schema Implementations In-Reply-To: <8A69033E02ED29419B0F43AD421CEC3A47D984@novaxcg01.csw.l-3com.com> References: <8A69033E02ED29419B0F43AD421CEC3A47D984@novaxcg01.csw.l-3com.com> Message-ID: Hi Bob, Bob.Oneil@l-3com.com writes: > For example, if the XSD files contain an element named "Author" in > both files, GCC will report collisions on the class names even if > the elements are at different leafs of the XSD tree. > > [...] > > Perhaps you have other solutions that would remove this restriction. The recommended way to make the generated code from several unrelated schemas that use the same XML namespace coexist in the same application is to place the generated code for each schema into a separate C++ namespace. You can achieve this with the --namespace-map option. If your schema does not have a target namespace, you can still use this option with an empty string for the XML namespace, for example: --namespace-map =my_namespace Boris From Bob.Oneil at L-3Com.com Mon Mar 15 16:44:03 2010 From: Bob.Oneil at L-3Com.com (Bob.Oneil@L-3Com.com) Date: Tue Mar 16 08:59:05 2010 Subject: [xsde-users] XSDE Generates Different Base Class Return Value from post() after minor reductions to XSD schema file under Eclipse Linux 64-bit Message-ID: <8A69033E02ED29419B0F43AD421CEC3A47D98A@novaxcg01.csw.l-3com.com> I have a somewhat unexpected result from the xsde compiler that occurred after I modified an original version of an xsd file to simply remove some content. The conditions are very repeatable. The XSD files passed basic validation. The return value from the template to the post() method in the parser implementation template (net_mdl-pimpl.hxx) has changed from a pointer to the C++ mapped collection (as ::Settings* post()) to simply the object itself (as ::Settings). It was my understanding that the parser dynamically allocated the mapped C++ class returned from the call similar to the following: // Perform post processing class Settings* pSettings = Settings_p.post (); It was then up to the application to pass around this pointer to routines that needed the C++ mapped content, and to free the dynamic memory when done with the created object. By simply removing a few entries from the xsd file, the xsde compiler generates a different prototype in the class. Perhaps this reflects some basic misunderstanding I have in some of the specifics about xsde. This is using an Eclipse Project under Linux 64-bit Attached are a couple of Eclipse Projects that provide the generated files, and the xsd schema. For these projects, xsde was installed to '/opt'. FROM: // Parser aggregate for the Settings element. // class Settings_paggr { public: Settings_paggr (); void pre () { this->Settings_p_.pre (); } ::Settings* post () { return this->Settings_p_.post_Settings (); } ::Settings_pimpl& root_parser () { return this->Settings_p_; } static const char* root_name (); static const char* root_namespace (); ::xml_schema::parser_error _error () { return this->Settings_p_._error (); } void reset () { this->Settings_p_._reset (); } TO: // Parser aggregate for the Settings element. // class Settings_paggr { public: Settings_paggr (); void pre () { this->Settings_p_.pre (); } ::Settings post () { return this->Settings_p_.post_Settings (); } ::Settings_pimpl& root_parser () { return this->Settings_p_; } static const char* root_name (); static const char* root_namespace (); -------------- next part -------------- A non-text attachment was scrubbed... Name: Reference Projects.rar Type: application/octet-stream Size: 67541 bytes Desc: Reference Projects.rar Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20100315/7ae00a37/ReferenceProjects-0001.obj From boris at codesynthesis.com Tue Mar 16 09:32:46 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 16 09:22:08 2010 Subject: [xsde-users] XSDE Generates Different Base Class Return Value from post() after minor reductions to XSD schema file under Eclipse Linux 64-bit In-Reply-To: <8A69033E02ED29419B0F43AD421CEC3A47D98A@novaxcg01.csw.l-3com.com> References: <8A69033E02ED29419B0F43AD421CEC3A47D98A@novaxcg01.csw.l-3com.com> Message-ID: Hi Bob, Bob.Oneil@l-3com.com writes: > I have a somewhat unexpected result from the xsde compiler that occurred > after I modified an original version of an xsd file to simply remove > some content. > > The return value from the template to the post() method in the parser > implementation template (net_mdl-pimpl.hxx) has changed from a pointer > to the C++ mapped collection > > (as ::Settings* post()) to simply the object itself (as ::Settings). > > It was my understanding that the parser dynamically allocated the mapped > C++ class returned The C++/Hybrid mapping divides all generated classes into fixed-length and variable-length. Fixed-length types are basically types that don't contain members that would require dynamic memory allocation in order to copy. For example, a type containing two elements of type int with minOccrus == maxOccrus == 1 would be fixed-length. On the other hand, a type containing an element of type int with maxOccrus == 'unbounded' would be variable-length since it will require dynamically-allocated memory to store the sequence data. For efficiency, fixed-length types are stored and passed by value. Variable-length types are stored and passed as pointers to dynamically- allocated instances. For more information on this, see Section 4.2, "Memory Management", in the C++/Hybrid Mapping Getting Started Guide: http://www.codesynthesis.com/projects/xsde/documentation/cxx/hybrid/guide/#4.2 So in your case you probably removed some "variable-length" content from your schema which made the Settings type fixed-length. If you want the old behavior (i.e., dynamic allocation), then you can do: Settings* s = new Settings (p.post()); Boris From iftroja at live.com Thu Mar 18 09:53:19 2010 From: iftroja at live.com (Kjell Svensson) Date: Thu Mar 18 09:53:29 2010 Subject: [xsde-users] Will XSD/E support XML Schema 1.1 new features? Message-ID: I have problems with how to handle our XML schema versions, to be backward/forward compatible etc.It looks like version 1.1 introduce some new features that could help e.g. openContent.Are there any plans if/when XSD will support 1.1? /Troja _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 From boris at codesynthesis.com Fri Mar 19 03:50:29 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 19 03:39:40 2010 Subject: [xsde-users] Will XSD/E support XML Schema 1.1 new features? In-Reply-To: References: Message-ID: Hi Kjell, Kjell Svensson writes: > I have problems with how to handle our XML schema versions, to be > backward/forward compatible etc. It looks like version 1.1 introduce > some new features that could help e.g. openContent. Are there any > plans if/when XSD will support 1.1? We are planning to support some of the features in 1.1 eventually, though it is not clear when, since the specification is still changing and there is no definite timeline from W3C when it will become a recommendation. Also some of the new features proposed for 1.1 may not be practical for embedded systems. For example, assertions would require a complete XPath processor plus the construction of a generic XML sub-tree to evaluate the expression on. Neither of these two requirements are realistic for most embedded systems. Also, it would be helpful for you and others interested in XML Schema 1.1 support to provide a list of 1.1 features that you are planning to use in your future schemas and would like to see supported in XSD/e. This way we can get a better idea about which features the users of XSD/e are interested in. Boris From iftroja at live.com Mon Mar 22 04:29:09 2010 From: iftroja at live.com (Kjell Svensson) Date: Mon Mar 22 04:29:17 2010 Subject: [xsde-users] Will XSD/E support XML Schema 1.1 new features? In-Reply-To: References: , Message-ID: Hello I'm a newbie on XML Schemas, so I'm probably not the right one to put requests on what mightbe good to implement or not. However when I have read about how to version xml schemasI get the impression that 1.1 will have better support, e.g. by using openContent. Our requirement is that the xml shall be possible to extend. Defined elements cannot be removed. And we shall follow the rule "must ignore any attribute or element that we do not recognize" /Kjell > Date: Fri, 19 Mar 2010 09:50:29 +0200 > From: boris@codesynthesis.com > To: iftroja@live.com > CC: xsde-users@codesynthesis.com > Subject: Re: [xsde-users] Will XSD/E support XML Schema 1.1 new features? > > Hi Kjell, > > Kjell Svensson writes: > > > I have problems with how to handle our XML schema versions, to be > > backward/forward compatible etc. It looks like version 1.1 introduce > > some new features that could help e.g. openContent. Are there any > > plans if/when XSD will support 1.1? > > We are planning to support some of the features in 1.1 eventually, > though it is not clear when, since the specification is still > changing and there is no definite timeline from W3C when it will > become a recommendation. > > Also some of the new features proposed for 1.1 may not be practical > for embedded systems. For example, assertions would require a complete > XPath processor plus the construction of a generic XML sub-tree to > evaluate the expression on. Neither of these two requirements are > realistic for most embedded systems. > > Also, it would be helpful for you and others interested in XML Schema > 1.1 support to provide a list of 1.1 features that you are planning > to use in your future schemas and would like to see supported in > XSD/e. This way we can get a better idea about which features the > users of XSD/e are interested in. > > Boris _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969 From boris at codesynthesis.com Mon Mar 22 12:23:27 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 22 12:12:24 2010 Subject: [xsde-users] Will XSD/E support XML Schema 1.1 new features? In-Reply-To: References: Message-ID: Hi Kjell, Kjell Svensson writes: > However when I have read about how to version xml schemas I get > the impression that 1.1 will have better support, e.g. by using > openContent. Yes, that's probably correct. Note, however, that 1.1 still has some way to go before it becomes mainstream. The best indication of that is the fact that there is only one XML Schema processor that support this version, and, in fact, only parts of it. So unless your schemas are for the internal use only, it won't be wise to reply on the features found in 1.1 since others may not have a processor for their platform/loanguage/application that supports this version. > Our requirement is that the xml shall be possible to extend. > Defined elements cannot be removed. And we shall follow the > rule "must ignore any attribute or element that we do not > recognize" This can be achieved with wildcards (xsd:any and xsd:anyAttribute) in 1.0, though perhaps not as elegantly as in 1.1. The basic idea boils down to this: There could be some difficulties with particle attribution (which were also addressed in 1.1) if you have sequences of elements at the end but overall it can be made to work (in XSD/e you can disable UPA checking in the compiler and the generated code will do the right thing). Boris From iftroja at live.com Wed Mar 24 09:30:14 2010 From: iftroja at live.com (Kjell Svensson) Date: Wed Mar 24 09:30:22 2010 Subject: [xsde-users] Will XSD/E support XML Schema 1.1 new features? In-Reply-To: References: , Message-ID: Thank you for your information I have found a good article on XML versioning andby doing what he propose will not need any 1.1 support in XSD/E. http://davidbau.com/archives/2004/01/index.html /Kjell > Date: Mon, 22 Mar 2010 18:23:27 +0200 > From: boris@codesynthesis.com > To: iftroja@live.com > CC: xsde-users@codesynthesis.com > Subject: Re: [xsde-users] Will XSD/E support XML Schema 1.1 new features? > > Hi Kjell, > > Kjell Svensson writes: > > > However when I have read about how to version xml schemas I get > > the impression that 1.1 will have better support, e.g. by using > > openContent. > > Yes, that's probably correct. Note, however, that 1.1 still has > some way to go before it becomes mainstream. The best indication > of that is the fact that there is only one XML Schema processor > that support this version, and, in fact, only parts of it. So > unless your schemas are for the internal use only, it won't be > wise to reply on the features found in 1.1 since others may not > have a processor for their platform/loanguage/application that > supports this version. > > > > Our requirement is that the xml shall be possible to extend. > > Defined elements cannot be removed. And we shall follow the > > rule "must ignore any attribute or element that we do not > > recognize" > > This can be achieved with wildcards (xsd:any and xsd:anyAttribute) > in 1.0, though perhaps not as elegantly as in 1.1. The basic idea > boils down to this: > > > > > > > > > > > There could be some difficulties with particle attribution (which were > also addressed in 1.1) if you have sequences of elements at the end > but overall it can be made to work (in XSD/e you can disable UPA > checking in the compiler and the generated code will do the right > thing). > > Boris _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969