From travelwitek at gmail.com Fri Jan 28 04:39:25 2011 From: travelwitek at gmail.com (Witek Piet) Date: Fri Jan 28 04:39:33 2011 Subject: [xsde-users] XML schema validation (XSD) and XSD/e Message-ID: Dear Support, I am using XSD/e for serialization and parsing of data. I as I have a question regarding which type of validation is performed by XSD/e. More specifically I have added the following to my XSD-file: I had expected that the parser/serialization code generated by XSD/e would include validation of the range for elements of type trigger_interval - but it does not. Could you please elaborate on which type of validation XSD/e provides? Thanks in Advance, Witek From boris at codesynthesis.com Fri Jan 28 05:35:25 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 28 05:21:03 2011 Subject: [xsde-users] XML schema validation (XSD) and XSD/e In-Reply-To: References: Message-ID: Hi Witek, Witek Piet writes: > > > > > > > > I had expected that the parser/serialization code generated by XSD/e would > include validation of the range for elements of type trigger_interval - but > it does not. The numerical facets are not supported in the current release (3.1.0) but are implemented in the upcoming 3.2.0 (it is in the final testing stage and should be out in the next few weeks). If you would like, you can try the beta version, which is available here: http://www.codesynthesis.com/products/xsde/download.xhtml Generally, the list of validated XML Schema constructs for parsing is listed in the C++/Parser Getting Started Guide: http://www.codesynthesis.com/projects/xsde/documentation/cxx/parser/guide/#A And for serialization -- in the C++/Serializer Getting Started Guide: http://www.codesynthesis.com/projects/xsde/documentation/cxx/serializer/guide/#A The above documentation is for 3.1.0 so if you would like to see the list for 3.2.0, you will need to download the beta. Boris From ivan.lelann at free.fr Fri Jan 28 09:24:32 2011 From: ivan.lelann at free.fr (Ivan Le Lann) Date: Fri Jan 28 09:24:41 2011 Subject: [xsde-users] Feature proposal : throw an exception when accessing non-present member In-Reply-To: <116598094.2848321296224641414.JavaMail.root@zimbra36-e6.priv.proxad.net> Message-ID: <294721245.2848341296224672302.JavaMail.root@zimbra36-e6.priv.proxad.net> Hi all, Here is the typical generated code for a variable length member. inline ::bar_type& foo_type:: bar () { return *this->bar_; } Obviously, calling bar() when bar_present() is false is an access violation. For a fix length member, you get something between a random value or a default one. I consider current behavior as both inconsistent and tricky. Now, how about throwing an exception with very basic information? I dislike having to do C-style checks to show decent error report. The concern is mostly for variable length elements but I'd vote for consistency. Should this proposal meet success, I'd be glad to help with an implementation. This should probably be an option, conflicting with no-exception, and whose default value has to be carefully chosen. Now one question is left wide open: How to apply this to mandatory elements/attributes? One could consider XML validation exceptions sufficient for those, but that would keep the process of building from scratch hazardous ... Regards, Ivan From boris at codesynthesis.com Mon Jan 31 10:16:07 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 31 10:01:03 2011 Subject: [xsde-users] Feature proposal : throw an exception when accessing non-present member In-Reply-To: <294721245.2848341296224672302.JavaMail.root@zimbra36-e6.priv.proxad.net> References: <116598094.2848321296224641414.JavaMail.root@zimbra36-e6.priv.proxad.net> <294721245.2848341296224672302.JavaMail.root@zimbra36-e6.priv.proxad.net> Message-ID: Hi Ivan, Ivan Le Lann writes: > Obviously, calling bar() when bar_present() is false is an access violation. Or, more precisely, it is a programming error that leads to an access violation. One should never call an optional member accessor without first checking for its presence. > Now, how about throwing an exception with very basic information? I think that's a bad idea. This is a programming error, not an unexpected condition. It will also negatively affect performance and object code size. > I dislike having to do C-style checks to show decent error report. Having the _present() accessor return false should no be an error. If it is, then you should make this member required (in the schema). Boris