[EMAIL PROTECTED] wrote on 05/08/2006 01:54:39 PM:
> I guess my first impression would be to break the correspondance to xml > schema and make the type non-complex (in terms of the feature model). I like this. Here my longwinded rant: XML/XML Schema should never be considered to be a feature model. It is an encoding of a model. "Breaking the correspondance to xml," as you say, is a recognition that we as programmers/data admins/users are allowed to choose a mapping between a well defined model and the XML representation. In this case, there's two encodings: JTS Coordinates represent 19107 "GM_Object"s, and so does your list of ordinates. This implies: 1] No hardcoding. The mapping should be flexible. (e.g., what if we encounter some _other_ data representation which we desire to map to a coordinate? Or X/Y/Z to data fields instead of to a geometry? How do you know X/Y/Z are always spatial? They could be volts or frequency or power.) 2] Consistency with Jody's "the data are infallible" attitude. :) One could map from a non-compliant XML document to a legitmate feature model, so long as one takes the time to understand how the default mapping falls short. (e.g., the data can indeed be infallible at the same time the XML representation of the data is non-conformant.) Note that a flexible encoding scheme which maps to a well understood (and valid) model does in fact allow you to read more data files. It also isolates a particular files' quirks to that particular file (or set of similarly encoded files). Preferably, this encoding scheme should be extensible at runtime. Consider this: GML (19136) encodes constructs which are defined in many other standards (Dictionaries/tools: 19103; Geometry: 19107; CRS: 19111; Coverage: 19123; etc.). Each of these definitions provides rules for what is legal and what is not. However, it is highly unlikely that the XML Schemas for GML will permit only legal constructs. Many illegal combinations are also possible. (Take, for example, anything which is "conditionally mandatory." XML Schema just does not have the expressive power to represent this.) Or posit that XML Schema falls out of fashion and GML 3.3 encodes these _same_ constructs in RelaxNG. Suddenly some of the XML Schema loopholes are closed while new ones are opened, yet _legal_ GML documents will validate against either schema. But in the mean time, Jody is going to get customers who whine that their documents validate against the GML schemas, so they *must* be valid. It will not occur to Jody that validated documents can indeed violate the models upon which GML is based( :) ). Jody must then patch the core Feature Model so that it allows a GML representation which slipped thru the cracks. Now the Feature Model applies this "fixed" mapping to all documents, even though some other user may use the same GML loophole to represent a different concept. Long story short: XML is not the Feature Model, and users/clients should be able to specify how to go back and forth between the Feature Model and XML (although a good set of default rules should be provided.) Hardcoding bad. Plugin good. :) Bryce PS: Rules for encoding are provided in 19118 ( http://www.ncits.org/ref-docs/ISO_DIS_19118.pdf, or Google OGC 19118). GML 3.1.x does not follow these rules, but rumor is that 3.2 (19136) will. ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
