Hi Adrian, I'll try to answer some of your questions, inline.
On Monday 03 October 2005 16:12, Adrian Custer wrote: > A. Questions about the discussion and docs: > ========================================== > > FeatureTypes for GML appears the oldest doc and no longer relevant: true > The document: > http://docs.codehaus.org/display/GEOTOOLS/FeatureTypes+for+GML > appears to be the oldest. Is this still relevant? Did it result > in what Geotools 2.1/2.2M0 is currently? yes. The ouput of that job done by Chris Holmes and David Zwiers as a first attempt to support complex types relied in some of the capabilities of the current 2.1 typing system, like using Filter for facets and directly exposing some internal AtttributeType implementations to make the API clearer. Unfortunatelly, they was stuck on the need of maintaining backward compatibility on the API, and though partial support for complex types was achieved, the difficult cases like 'choice' and 'all' were harder to implement thant "sequence" without breaking it. > When the doc talks > about GML, is this an abstract model of what GML could be, is it > specifically GML2 or is it about GML3? I think it is more about providing a typing system for GIS applications that can be used to represent GML* schemas, rather than targeting a specific GML version. > > The main proposal seems to build on "Comm.Schema Supp.and Compex Types": > The series of docs under: > http://docs.codehaus.org/display/GEOTOOLS/Community > +Schema+Support+and+Complex+Types > appear to be in chronological sequence all the way to > http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Proposal > so that appears understandable (once someone has grokked how > they fit into the doc hierarchy). you got it. > > Two other docs may or may not be recent: > How do > http://docs.codehaus.org/display/GEOTOOLS/Review+of > +FeatureType+Models This is recent. It was Jody's blackboard in the process of supporting our work on the complex datastore project > and > http://docs.codehaus.org/display/GEOTOOLS/Meta > +Information+Infrastructure > fit in? and this is a document on the work being done by Paolo Rizzi & Luca S. Percich for their organization, that we're now trying to figure out if/how it fits as a configuration layer for the complex datastore by one hand, and how it should be extended to support the new typing system by the other hand. > > Which api is current? > Most critically, there are 3 proposed api: > 1) bottom of > http://docs.codehaus.org/display/GEOTOOLS/FeatureType > +Survey > 2) under first draft of > http://docs.codehaus.org/display/GEOTOOLS/Feature+Model > +Discussion > and (3) in > http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Proposal > Which is the current version? the last one. It is the result of Jody and me joining of requirements requirements. Jody made the interfaces that are in a svn spike module and I just started implementing business driver test cases today > > > > > B. Questions on the Proposed interfaces: > ======================================= > > * What's the status of the work? > The ComplexDataStore+Project page says that the Test suite, the > DataStore, and the GML Production Enhancements are currently > frozen. Is this still true? No it is no more true since today. The project is already alive, and the schedule was updated on the project page: http://docs.codehaus.org/display/GEOTOOLS/ComplexDataStore+project#ComplexDataStoreproject-Projectdeliverables > > * Is there any proposal for the input/output procedure? > I do not yet understand your working vision is of the processing > of schema/gml files during input or output. I can imagine a > series of steps for input: user accesses a gml doc, gt validates > gml, gt gets schema, validates schema, parses schema into a tree > of defined featureTypes, parses gml, first, creating and > validating each feature and, second, adding the feature to a > 'catalog'(sensu uDig), gt discards the schema tree or keeps it > in a schema catalog. I can also imagine a similar vision of the > output steps. > * What are the visions you are working with? > * How do you ensure the GML does not, through its internal xlink > refs, loop? (i.e. feature A embeds feature B, B embeds A) I don't know currently, though I can forsee a kind of control process that ensures a Feature is encoded only once, the first time it appears, and the rest of appereances using a proxied feature. > * How do you guarantee that a round trip, possibly with feature > modification, will produce the same doc? I imagine it must be > possible for a round trip to result in a schematically correct > but different gml than the original. not quite sure I'm getting it. Let me see if I correctly understood your questions: the i/o procedure is dictated by the DataStore API. Note the whole work is not focused at parsing/producing GML documents, but to support DataStores that are able of dealing with complex types, wether it is a GML based datastore implementation, or a database one. > > * How is GeoAPI participating? > I gather that both the pure Geotools and the pure GeoAPI efforts > were merged. Is this correct? its kind of correct. Jody is providing lots of his 'spare' time to ensure both worlds finally join on a common API. I'm more focused on fulfilling the project needs, since its under contract work. Jody acts as QA and the glow bettween geotools and geoapi. > > * What is the API stability guarantee of Geotools across version > numbers? > Is stability limited to "if we deprecate it in one minor version > (i.e. x in #.x) version, we can remove it the next"? Jody? > > * What's the aim of 2.1.x and 2.2.x? > G.t. 2.1.x seems to do 'Simple Features' more or less > completely. Is the idea that it will continue to do this while > 2.2 aims to support GML3? That is, is there any idea to complete > and stabilize the simple feature support separate from the > effort to support complex features? It has no to be separate, but a concern of the current work is to not impose extra complexity for the simple features cases, thus providing a "simple view" on the API that keeps to the greater extent possible apart from the complex stuff. > > * Do all GML files necessarily have a schema? AFAIK, yes. as long as a db table has it > It appears that it would be possible to define a schema on the > fly based on the contents of a GML file. This seems useful also > for GML docs where the schema were inaccessible (internet > down/origin disappears). Does G.t. intend to support this? It could be possible. I guess that if no schema is present, a GML file could be treated just like a simple FeatureCollection? hope to have answered most of your concerns, if not please bug me/us. And thanks for worring about all this. Gabriel. > > That's it for now. > --adrian > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
