In my mind this isn't so much about building it to a particular exchange
format - it's just making our model more granular. There are a number
of different java objects for dates and times, but we squash them all in
to one Temporal Attribute Type. This is just letting that attribute
Type have knowledge of a few more types.
I don't think this leaves wfs 1.1 and gml3 encoding out in the cold, or
at least I hope it doesn't - what happens if the xml schema data types
are more granular than existing java classes? Are we limited there to
only doing XML output types of things that have Java classes?
Would the solution be to make new Java classes that better deal with the
granular information? I think that could work with this if need be...
we could extend Date to be particular kinds of dates.
Chris
Justin Deoliveira wrote:
Hi Andrea,
This approach will leave wfs 1.1 and gml3 encoding out in the cold since
it takes a different approach to this. It relies on coming up with
defined mappings from java classes to xml schema data types. I admit
that in the case of dates the mapping is not clean.
Also, building things specific to a particular exchange format or
presentation directly into the data store doesn't seem quite right. I
mean what do we do if we want to encode features in another format that
has different data types than that of xml. Do we have to update each
data store again to provide the information in order to map correctly
for that format too?
Its a tough one. On the one hand I want to see the mappings from java to
xml separated into a single place. On the other hand the java classes do
not give us the granularity we need.
-Justin
Andrea Aime wrote:
Hi,
tomorrow I'd like to go and fix GEOT-620, so that our GML encoded
date do respect the data store settings.
Basically, I want to extend TemporalAttributeType to have an enumeration
(list of ints, codelist?) that allow us to say which kind of Date is
that, xs:date, xs:datetime, xs:time, and have feature types and features
encoded accordingly.
It would be up to the datastore to provide the right information into
the feature type, if missing, we default to datetime.
I'm going to fix postgis, other datastores may follow at their
leisure... at the moment we're broken in any case, our GML output
never really validates since we don't respect the xml schema
restrictions on the xs:date* types.
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
