I've been thinking about this, and now I am really confused! I think I can summarize my confusion by saying this:
I don't think we will need to introduce a uniquely identified FeatureSchema and/or a FeatureType if we introduce a restriction for unique Layers. (Or at least a way to associate a unique identifier with Layers.) I can associate any type or constraint or restriction on a uniquely identified Layer as easily as I can a uniquely identified FeatureSchema. After thinking about it I believe that it is better to work with Layer objects than it is FeatureSchema objects. This is because we don't expose FeatureCollections or FeatureSchemas to the user at this point. We expose Layers. A user won't want to apply a attribute value range or other constraint to a FeatureSchema, they'll want to apply it to a Layer. If I'm a user that doesn't subscribe to this list I don't even know that FeatueSchemas and FeatureCollections exist. I say we keep it that way. The only downfall that I can think of to this system is that If a programmer is interested in using OpenJUMP's feature model as a library in an external program, but doesn't want to use Layers they won't have the control we are talking about. Maybe Paul has some reasons why this won't work in his situation. The Sunburned Surveyor On 6/12/07, Martin Davis <[EMAIL PROTECTED]> wrote: > FeatureType seems like a good name for this. > > It does seem like this could be added without too much risk right now, > with very little semantics or functionality around it (other than what > Paul is presumably building). > > I guess if there's a real need for this functionality it will become > obvious as people ask for more functionality exposed for it. > > I'm just a bit worried that this whole area in general has no very clear > model to follow. Every system seems to do something a bit different. > If there's no initial overall vision of where this is going, we risk > building off in directions which are very hard to corral back later. It > would be nice to pick an existing model and follow or extend it. Maybe > the Geodatabase model is a good one to look at. They certainly follow > the relational paradigm pretty closely, which will make Landon happy > 8^) Me too, actually - I don't have anything against the relational > paradigm, and it's certainly a lot more battle-hardened than the object > DBMS world. > > Sunburned Surveyor wrote: > > I must weigh in with Paul on this one guys. I see a lot of potential > > uses for uniquely identifying FeatureSchemas. I guess that I would > > call this a FeatureType. If you are curious about the applications of > > defining and uniquely identifying FeatureTypes just take a look at the > > ESRI Geodatabase. (For example, FeatureTypes would allow you to > > specify a range of allowed values for an attribute.) I believe in ESRI > > FeatureTypes are called FeatureClasses. > > > > I also don't think that it is unreasonable to specify that an OpenJUMP > > project contain no duplicate FeatureTypes. However, I do see that we > > allow Layers to have the same name, which I think is a bad thing... I > > guess that I never noticed this before. > > > > Martin wrote: "This all seems like a lot of extra complexity to > > support something that at the moment is really only your own use case. > > Perhaps you should > > publish this as a plugin for now, and if it gets used a lot then the > > JUMP project can think about incorporating it in the core." > > > > I would agree with Martin on this point. I don't think it would be to > > difficult to encapsulate a system for uniquely identifying > > FeatureSchema's in a plug-in. You'd could automatically add the Layer > > name (as the unique ID for the FeatureSchema) and a reference to the > > FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If > > the user tried to create a Layer with a duplicate name you could > > create an error message. > > > > Or you could prompt the user to enter a name for a FeatureSchema when > > creating a layer, although this might be more confusing for them. > > > > I think the best solution would be to allow users to assign a unique > > FeatureType or FeatureSchema to the Layers that they select (after the > > Layers had been created, of course). That way we aren't forcing this > > on users that have no need for it. > > > > You could capture the relationship between the FeatureSchema, Layer, > > and unique FeatureSchema indentification at the time that the user > > made the association. If you want it to be really easy you could > > automatically fill the unique id text box with the name of the Layer > > that the user selected for the association. That would solve your > > reflection problem. You would never need to ask a FeatureSchema if it > > had a unique name. You could just see if there was a unique id > > associated with the instance of FeatureSchema by asking the plug-in. > > > > If Paul think's he would be interested in doing something with > > FeatureTypes or uniquely identified FeatureSchemas via a plug-in I'd > > be interested in the design, as I think this really is something that > > I will want to tap into in the future. > > > > The Sunburned Surveyor > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
