Hi Peter, I apologize for things being a bit unclear. Let me try to explain better.
So when the parser sees an element which has a type of xsd:datetime it will load the XSDateTimeBinding to parse it. And yes, currently this binding will parse the string into a Calendar object, and specifically an XMLGregorianCalendar as you state. So yes, after the fix it will actually return a java.sql.Timestamp since it is the mapping that has been agreed on. The parser has quite a learning curve as you are finding out :). The docs are a good overview introduction but unfortunately it takes some time to really learn and work with it. Feel free to hop on geotools irc channel freenode#geotools and ask questions in person. I would be happy to spend some time trying to make things a bit clearer for you. -Justin Bolla Péter wrote: > Hi Justin, > >> Regardless... the parser is able to convert between the types it needs >> so its not always a problem if they dont line up perfectly. > > I don't really understand this. The parser reads the xsd, and decides > what type it should return based on that. Isn't that the way? So if it > sees xsd:datetime, it returns GregorianCalendar now, but will return > java.sql.Timestamp after the fix. > I gues this page: > http://docs.codehaus.org/display/GEOTDOC/2+Binding+Execution is just > about this, but it's not absolutely clear for me... :( > > > Peter > >> As for taking the types generated by the jaxp generator I would agree >> with you. Use them as a proposal... and change as need be. As shown here >> sometimes the mapping between xml schema types and java types is far >> from perfect. And indeed this is the same strategy that I used for >> generating beans (with emf) from the wfs schema. The types generated out >> of the box were not perfect so I had to change them. >> >> -Justin >> >> Bolla Péter wrote: >>> Hi Justin, >>> >>> I have some time again, to work on the gpx parser, and found a problem. >>> There is a date field (actually there are more of them, >>> type="{http://www.w3.org/2001/XMLSchema}dateTime"), which the jaxp >>> translated to XMLGregorianCalendar attributes. The problem is, that the >>> XML parser returns GregorianCalendar. This raises the question, that >>> should I treat the jaxp generated beans as a "proposal", and adjust the >>> types as I need (e.g. int or double instead of BigDecimal)? Or do I have >>> to leave that code alone, as I can't change the XSD either? >>> >>> Thank you, >>> Peter >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4007,46cb1ee3159011336712104! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
