| [udig-devel] Re: Intros ... ie an FM victim |
Bryce L Nordgren wrote:
Taa :-)John Reid <sdiowl@xxxxxxxxxxxx> wrote on 07/25/2006 09:02:18 AM: Know that feeling :) I think these would be handled as UML packages stored in XMI fragments that could be imported into the model by the tool (19109 Fig. 9). A customized editor would probably import some packages (e.g. 19107) automatically upon creation of a new model.1] My understanding is that the UML encoding of Geographic features was handed to us from on high in 19109, Clause 8 (I think). Are you talking about drawing out the required UML (e.g. '107, '108, '111, '112, '115...) in a specific UML tool? By profile I am referring to the UML extension mechanisms. From the bible (UML Reference Manual):Or are you talking about something else when you say a "profile"? Perhaps drawing out a particular subset of '107, etc. "Extensions are organized into profiles. A profile is a coherent set of extensions applicable to a given domain or purpose. ... The extensibility mechanisms are stereotypes, tagged values, and constraints. ... A profile is a package that identifies a subset of an existing base metamodel ... and defines stereotypes and constraints that may be applied to the selected metamodel subset." So we would have the stereotype <<application schema>> applied to packages in the model. GF_FeatureType would be defined as a stereotype <<geographic feature>> on classes, GF_SpatialAttributeType as <<spatial>> on an attribute etc. Apparently it is possible to define additional classes at the metamodel level in a profile, however I'm hoping that the stereotype approach should enable the use of UML tools without any customizations to diagram editors and ??? Fingers crossed :-) :-)2&3 ] Bravo! I'm going to cross those bridges when I come to them. It would be nice if that problem just disappeared. XMI can be used to create schemas from a model and encode objects. Wouldn't it be nice if we didn't have to worry about specialized formats and just use one that someone else has written the codecs for... Oh well.4] ? Which ISO compliant XML schemas? GML 3.2.0 / ISO 19139? And here was I thinking I was already there ;-) Isn't that a prerequisite for working on feature models ;-)Beware of the GT/GeoAPI Feature Model. You may get some data which is not strictly ISO compliant (making it difficult to encode it in an ISO compliant way.) Jody insisted on allowing for non-OGC non-ISO features merely because customers generate all manner of garbage XML and he's afraid to call them wrong. :) Due to much whining on my part, they made allowances for people who play by the rules, but I think this is optional. It has been a while since I looked at the Feature Model. I suggest you examine it to ensure that you can extract an appropriate guarantee that feature schema you receive will be encode-able...Pay particular attention to duplicate feature attributes. Jody, can you direct this fine young man to the ISO subset of the feature model? Also beware of GML. Making an XML schema seems to invite people to disregard all else. The XML Schema for GML permits more than is allowed by the text of the GML standard, and also more than is allowed by the data model GML is supposed to represent. People will argue that anything that validates against the schema should be considered "legal" even if it conflicts with the text of the GML standard or the model that GML encodes. You're going to have to defend your #4 from incorrect allegations of it being broken and resist the temptation to break your codec for everyone just because someone has produced or needs to receive data which is broken in a specific way. Down that road lies madness. I'm looking at UML because I hope that a stock standard UML modeling tool can be used, either straight out of the box or with minimal customizations. I'm not sure what the relationship is between the UML2 project and Ecore. AFAIK Ecore is based on a subset of MOF 1.x whereas UML 2.x and MOF 2.X share a common core infrastructure. I do recall reading somewhere that a UML -> Ecore -> UML results in a loss of information, and I think stereotypes might be one of the victims.Not that I have any strong feelings on the issue. :) Nope not me. Not yet anyway. Algorithms could be documented using the documentation tag. I can't see any other approach for the time being. Someone out there might have a brilliant solution, but I'm just learning to crawl ;-)The next two paragraphs are intended to convince you that you need to declare your scope before it explodes. :) Don't get discouraged! I want to see UML schema representations happen!! How do you intend to handle Operations? When a geographic feature is specified to have some sort of behavior, how do you want to match it up with a local version of code in the current environment? Can't code it in UML! Reverse engineering of models has me scared. Again I'm going to worry about that one further down the road. Or it can be someone else's headache... IIRC the OMG's Common Warehouse Metamodel defines a thesaurus-like feature for mapping concepts. I think ISO JTC1 SC32 WG2 is in the process of defining similar functionality. However at the moment I think the ability to publish models and provide the capability to create datastores from a given application schema is the priority.More generally, say you have a shapefile containing roads which came from some random source. Separately, you have an ISO compliant Roads schema which you have been working with (maybe even coding against: routing algorithms and whatnot.) Can you map the feature attributes in your shapefile to identically-defined "standard" attributes in the Roads schema, thereby making all your hard "routing" work available to you? Thanks for your illuminating feedback :-) John |