Apologies for missing the meeting had a interview at the time, bad scheduling on my part.
First on releasing, rc2 on the 14th sounds fine to me. And I think it'd be fine if that slipped a few days, we should announce by the 19th though.
For the 1.6.0 release, what actually would be fine is to put it out like Jan. 2/3. We've actually seemed to have developed a bit of a tradition with not doing a big announcement until the .1 or .2 release, so we can stick with that. That way we can get the basics of the documentation in place for 1.6.0, and for 1.6.1 we can have all the nice screencasts, and by that time I believe TOPP should have someone who can help out on those.
As for the discussion on versioned feature collections. First off there was a bit of confusion why we needed this for the spec. The spec is at: http://www.openplans.org/projects/opencore/maps-part-1 The reason we need it in my mind is not really the history or just the comments, it's more the requirement that each pop-up display who made the note and when they made it. This seems to be required for every pop-up, and thus we need it on every feature. We could do a GetLog request everytime someone makes a pop-up, but that will make things feel slow.
I added on the lastUpdatedBy and updateTime. These are a bit outside the current spec, though we will need updateTime to track the history, and to compare against createdTime to tell if its a creation or an update. lastUpdatedBy is outside the scope of this spec, but as soon as we let people do real wiki editing I'm sure we'll want that, probably on the per feature level.
I like Tim's idea for a more generic ExtendedFeatureCollection. But I think it's sort of over-generalizing for an option we don't have plans to support. It's a cool point that we could just track logged in user and when things were last updated, but realistically to track that we'd have to modify the tables or have people create special tables to take advantage of it. So we'd need a new datastore, or generalize out what we have now. So I'd say for now we should stick with VersionedFeatureCollection. If there's a more generic use case in the future then we can refactor it. Indeed I could see extendedFeatureCollection including other kinds of auto generated information, read only fields that you wouldn't want to update. It should share implementation with the versionedfeaturecollection most likely. But the original point of the VersionedFeatureCollection was to include the version info at the FeatureCollection level. That attribute makes less sense in an extendedFeatureCollection, so we're probably going to still want to have the Versioning one. I suppose one could make a generic attribute in the extended one. But if we go down that road one could argue that the WFS FeatureCollection should have better extension mechanisms.
Also, note that Andrea and I talked a bit more about design, and we're thinking the best would be to also add a DescribeVersionedFeature operation, and the VersionedFeatureCollection would refer to that for its schema.
Chris