Some comments inline; wish I had time to sort this one out with you in more detail.
On Tue, Sep 8, 2009 at 1:07 PM, Ben Caradoc-Davies<[email protected]> wrote: > Jody Garnett wrote: >> That does not seem too strange. In this case I am guessing that >> GeologicUnit is a bit dynamic in nature > > This pattern is used for *every* complex-content property in GML. It is > required by the encoding rule. It is not specific to GeologicUnit or to > GeoSciML. > > The XSD looks like this: > OuterType <>--- InnerPropertyType <>--- InnerType > > The information model looks like this: > Outer <>-- Inner > > We use GeoAPI to represent the former. But is this right? I thought they were only doing this pattern to provide themselves choice between having it as a reference or inline? > Take, for example, gml:AbstractFeatureType, where three related GeoAPI > objects represent a feature and its geometry: > > gml:AbstractFeatureType > <>--- gml:LocationPropertyType > <>--- gml:AbstractGeometryType > > The information we are trying to convey has only two GeoAPI objects: > > Feature <>--- Geometry Hunting online gives me: http://xml.fmi.fi/namespace/meteorology/conceptual-model/meteorological-objects/2009/04/28/docindex12.html And thus: <element name="location" type="gml:LocationPropertyType"> <annotation> <documentation>Deprecated in GML 3.1.0</documentation> </annotation> </element> Note the name of "location"? I always viewed this as a descriptor that was being reused again and again. Right this is just an element that they are giving a name and using again and again - they are making it easier to follow a convention - ie documenting your LocationPropertyType with the name "location" when you use it as an element in your complex type. As for the actual LocationPropertyType it is a choice between several things as I mentioned above. An actual Geometry or a magic string or whatever. <complexType name="LocationPropertyType"> <annotation> <documentation>Convenience property for generalised location. A representative location for plotting or analysis. Often augmented by one or more additional geometry properties with more specific semantics.</documentation> <documentation>Deprecated in GML 3.1.0</documentation> </annotation> <sequence minOccurs="0"> <choice> <element ref="gml:_Geometry"/> <element ref="gml:LocationKeyWord"/> <element ref="gml:LocationString"/> <element ref="gml:Null"/> </choice> </sequence> <attributeGroup ref="gml:AssociationAttributeGroup"/> </complexType> Finally both of these are deprecated; what do they recommend to do now? Maybe they learned their lesson? > I am not convinced that the extra layer of indirection we currently use is > the correct use of GeoAPI. In my view, GeoAPI should represent the > information model and the encoder should convert to and from XML. It seems > to me that the GML encoding has influenced our use of GeoAPI, and we no > longer have a separation of concerns. In this case the separation of concerns was between the element name and the type; not sure I see the problem. In java we have a separation between a field name and a class type; same thing here. Jody ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
