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

Reply via email to