There's a fundamental problem with technology-specific introspection to create interoperability contracts.
Basically, you are bound by the specific persistence platform _and_ your specific introspection mechanism (and whatever "modes" you wish to complicate it with). So if you introspect for one technology you simply cant guarantee it will be isomorphic with the result in a different platform. The source and multiple target platforms have different meta-models and its a potentially lossy mapping. So, dont stress about it - you can just munge anything any way you like - even create random names for things and report the mappings as metadata - its going to be fragile anyway from an interoperability perspective, so not worth over-engineering. Choice, if you make up the data model on the fly, is to force into the target meta-model using 1) any arbitrary means you hard-code 2) allow users to configure a mapping algorithm The other choice is whether you report the mappings - but as there is a problem with any chosen protocol finding a canonical way to report such mappings. You will just have to force the syntactical conformance, and have no expectations that you can reliably make the results interoperate across meta-models. The output of your data isnt going to work with SLD unless it was directly output according to the SLD meta-model in the first place. Choosing a "perfect" algorithm requires finding common meta-meta-models in all the potential platform meta-models that you actual information model is being mapped to. Do you really want to attempt this? Its the role of formal information models, from which platform dependent application schemas can be derived, to define the interoperability you are expecting. You then only need to know how the object type maps to the information model to know if its the same. The corollary problem is of course that you also need to be able to compare content across platform meta-models reliably, but thats the same issue any way you look at the problem. Sorry to preach, but hope it helps you reach a pragmatic short term solution with minimal angst. Cheers Rob On Sat, May 8, 2010 at 12:04 AM, Jody Garnett <[email protected]> wrote: > Gak; interesting problem. It is almost like we need a "strict" mode and a as > you say a relaxed mode. > Jody > > On 07/05/2010, at 11:59 PM, Andrea Aime wrote: > >> Hi, >> say one has a table or a view that contains charaters that are invalid >> xml tag wise, such as spaces. For example, "My name". >> >> That makes it impossible to use that layer for WFS purposes for sure, >> but I've found that it makes it impossible to use the attribute for >> other things as well. For example, I cannot use it in SLD as a source >> of labels, or as a size, and so on. >> >> This is probably because the property accessors check for "word chars >> only" regexp before stating they can actually handle the value: >> >> static Pattern propertyPattern = Pattern.compile("(\\w+:)?(\\w+)"); >> >> I would say this is a case of being overzealous, since XML output >> is not the only possible use of the data. >> However, how can we tell apart that from a full xpath? >> I guess we could decide to let go a little and assume there are other >> chars past the word ones that make up a simple feature attribute? >> >> What do you think? >> >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
