Martin, I'm afraid you are on a higher level than I am in this discussion, and I may not completely understand all of the points you brought out in your e-mail. I am afraid this limitation of mine may be due to the fact that I never had any proper education in software design or architecture. My approach to software design in OpenJUMP comes from a very narrow perspective. I can only apply principles learned from my work as a surveyor and project manager to the problems I encounter in software design. Every time I think I have figured out the best way to do something in OpenJUMP someone points out a more obvious solution, or I find a more effective solution already implemented somewhere else in OpenJUMP's code.
I will try to have this discussion with you, as long as you patiently remember my limitations and that I often loose my understanding of the more technically complex things you bring out. I have this same problem with a lot of Larry Becker's posts, and posts from others as well. :] Martin wrote: "It seems to me that you are recapitulating the object-vs-relational debate that was raging strongly in the DB world in the late 90's." This was not at all my intention. I think it may have been a mistake to use the example with the database tables, although at the moment I can't think of another illustration that would have been more appropriate. The real point I was trying to make with the illustration is that it is often possible to model complex systems using relationships instead of containment or aggregation. I don't think that we are at all required to move to a "table-based" system in OpenJUMP to utilize this technique. I believe Java is more than capable at representing relationships between objects with the constructs available in the language. Martin wrote: "To put this more concretely, it would certainly be possible to represent complex features as sets of related tables." This isn't exactly the alternative I was hoping to present in my blog post. What I was really trying to present was the idea of modeling complex features using related objects, or relationships between objects. The only role I intended for "tables" in my alternative was as a way to view the attribute values of spatial and non-spatial features. (I agree this may not be the best way to view features, and that another GUI component might be better suited to this task. I think that is sort of what Paul has been working on lately.) Martin wrote: "But what would the user interface look like on top of this? How would Paul get his view of complex features? What would it mean in terms of UI to have a complex feature with either two geometries at one level, or an attribute which is itself a collection of spatial features? You would still need a way for the user to indicate how he wanted these to be rendered, how sub-features were created and destroyed, etc." I think you mention at least a few issues here, so let me address them one at a time. Let me start with the GUI that I would use to allow the user to navigate complex features modeled with relationships. I think Paul could "view" his complex features in a manner very similar to the one used now. Imagine something like a JTable that allows the user to click on a button that brings up a list of feature types related to the currently selected record in the table. The user could select the type of related feature that he wanted to view and another JTable would be created with the attribute values of all the features related to selected record in the first table that match the feature type chosen by the user. I know there are other approaches to viewing these relationships via a GUI. This is just one idea that wouldn't be too far from the GUI we currently use in OpenJUMP to display feature attributes. Martin briefly mentions another issue in the last comment of his that I quoted when he says: "...how sub-features were created and destroyed..." Martin follows this up later in his post when he says: "A concrete implication of this difference is that in a table-based model, you either have to explicitly define or explicitly manage the life-cycle of related sub-features. In an object-based model, this is controlled by the top-level feature, which is a simple model for the user to understand. " This is a cost to the alternative I described on my blog. It is honestly one cost that I overlooked when I was thinking about my post. However, I don't think it is a major drawback that would present us from using the alternative system. We would have to determine how to control the life-cycle of features participating in a relationship, and this would involve another layer of complexity. But I would argue that this would have to be done if we wanted to allow feature relationships anyways. In essence I think that we get more bang for our buck if we use feature relationships to model complex features. Not only do we get complex features, but we also get feature relationships. If we use a system based solely on aggregation of objects we loose the added bonus of being able to utilize feature relationships when we don't even care about representing complex features. I think the most compelling reason to use feature relationships to represent complex features instead of object aggregation or containment is because it can be built right on top of our existing feature model in JUMP. We don't have to rip out any major plumbing. Whenever I think about adding a feature or set of features to OpenJUMP, I ask my self this important question: "How can I do this with a plug-in, and without modeling the core." For me, modifying the core in an effort to add features should always be a last resort. (I feel differently about modifying the core to improve the quality and stability of the code.) The great thing about JUMP is that it was designed to facilitate this type of design philosophy. My blog post was simply presenting a way to represent complex features via a plug-in or plug-ins, without the need to change or add classes to the existing JUMP feature model. I think this is a topic that will deserve some more thorough discussion in the future. I think the general consensus is that we want to preserve the simplicity of OpenJUMP's current feature model. I am happy to see this, because it means no matter what we finally decide, the decision will be made carefully and with plenty of forethought. The Sunburned Surveyor On 6/8/07, Martin Davis <[EMAIL PROTECTED]> wrote: > Yes, I agree 100%. It's fine to look at adding functionality for > complex feature types, but this should not complicate the use of the > current simple feature model! > > Rahkonen Jukka wrote: > > Hi, > > > > As a user, I really hope you can keep the software as simple to use as it > > is nowadays even if the feature model goes complex... > > > > -Jukka Rahkonen- > > > > ________________________________ > > > > Lähettäjä: [EMAIL PROTECTED] puolesta: Markus Müller > > Lähetetty: pe 8.6.2007 19:04 > > Vastaanottaja: List for discussion of JPP development and use. > > Aihe: Re: [JPP-Devel] Alternative to a complex feature model... > > > > > > > > Hi Landon, Martin, > > > > (as so often) I agree with most points made by Martin. Perhaps a use > > case that I have in mind for a while is of interest here. > > > > In Germany (sorry...) there is a group of people who developed an > > object model for urban planning called "XPlanGML" (for those able to > > understand German, see http://www.xplanung.de). A "Plan" consists of > > several "layers" that itself consitst of different types of object > > sometimes having more than one geometry. The model was developed in UML > > and converted to a GML application schema. > > > > We implemented support for this GML application schema with deegree WFS > > and now a client that is able to display the semantic structure and even > > able to crate XPlanGML would be a real hit. If OJ would be extended to > > do this you would have to give it a complex feature model. But the main > > work would go into the user interface, because object information would > > have to be displayed in a tree-like structure able to display all > > connections between the objects. If you want to crate XPlanGML, you > > would have to define the object type of a newly created geometry, but > > also the place in the tree that represents the actual plan. > > > > > > Have a nice weekend, > > > > Markus > > > > > > Martin Davis schrieb: > > > >> SS, > >> > >> Good blog post. > >> > >> It seems to me that you are recapitulating the object-vs-relational > >> debate that was raging strongly in the DB world in the late 90's. It > >> seems like the RDB's have won that round (at least for the time being) > >> on the server side, but the object world is obviously in the ascendant > >> on the client side. > >> > >> I also think that this debate is mostly about implementation, but > >> doesn't really address the more fundamental issue of what the actual > >> semantic model is. And that's the important question, because that is > >> what is needed to motivate the design of the user interface and tools to > >> present it to the user. To put this more concretely, it would certainly > >> be possible to represent complex features as sets of related tables. > >> But what would the user interface look like on top of this? How would > >> Paul get his view of complex features? What would it mean in terms of > >> UI to have a complex feature with either two geometries at one level, or > >> an attribute which is itself a collection of spatial features? You > >> would still need a way for the user to indicate how he wanted these to > >> be rendered, how sub-features were created and destroyed, etc. > >> > >> Moreover, a table based model in not in fact simpler, it's more > >> complex! This is because it is more general, since relationships > >> between tables can model both association and aggregation. In contrast, > >> a complex hierarchical Feature is generally considered to model an > >> aggregation. A concrete implication of this difference is that in a > >> table-based model, you either have to explicitly define or explicitly > >> manage the life-cycle of related sub-features. In an object-based > >> model, this is controlled by the top-level feature, which is a simple > >> model for the user to understand. (RDBs usually handle this situation > >> by implementing "cascading delete on foreign keys" - but you don't get > >> this for free, you have to have a language to define this and the user > >> has to understand how to model this). > >> > >> To use another metaphor, I sometimes think of tables as the > >> assembly-language of object models. You can represent pretty much any > >> model you want using tables, but *you* have to to all the work of > >> defining and maintaining the model. An object model is presented at a > >> slightly higher level of abstraction, with some reasonable defaults > >> which can make it easier for a user to work with. > >> > >> My main point here is that I think the choice of object-vs-table is > >> orthogonal to the issues of defining the "mental model" that JUMP > >> presents to users via it's UI. *That* is the key thing to design - the > >> rest is just a question of implementation. > >> > >> Martin > >> > >> > >> Sunburned Surveyor wrote: > >> > >> > >>> I put up a post on my OpenJUMP blog about one possible alternative to > >>> a complex feature model. > >>> > >>> I haven't thought the idea through completely, and I don't have any > >>> plans on implementing the alternative described, but if you are > >>> interested in having the benefits of a more complex feature model in > >>> OpenJUMP you might want to read the post. If nothing else, I hope it > >>> presents an interseting concept. > >>> > >>> The post is here: > >>> http://openjump.blogspot.com/ > >>> > >>> 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 > >>> > >>> > >>> > >>> > >> > >> > > > > > > -- > > Dr. Markus Müller > > l a t / l o n GmbH (Hamburg) > > Gluckstr. 53a 22081 Hamburg, Germany > > phone ++49 +177 2470742 fax ++49 +228 18496-29 > > http://www.lat-lon.de http://www.deegree.org > > -- > > > > > > ------------------------------------------------------------------------- > > 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 > > > > > > -- > 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
