Chris Holmes wrote: > 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? The approach taken for wfs 1.1 was to come up with the subset ( ie. a profile ) of the xml types we support, and decide how we want to bind java classes to them. One benefit of which is that the mapping can be made once, and be shared across datastores.
With also the ability to create a different profile if different mappings are needed for a different output format. The "out in the cold" part was more just saying that it will be handling the problem differently, in a way that wont directly apply. So we will be maintaining two different solutions to the same problem. > > 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. > That is an idea. We could break out subclasses of date that meet exactly what we need them to do. Andrea recommended a library to me just today (cant remember the name ) which does this nicely. I guess the only downside would be that they aren't "standard" and other libraries we use probably wont recognize them ( for example the jaxb serialization that the parser uses to encode dates in xml ). > 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 >>> >>> >>> >> >> > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
