We need to distinguish the 'profile pattern' from the idea of a profile artefact.
A TimeSeriesObservation is a feature type that restricts an Observation by specifying the type of the "result" property. Thus it is a 'profile' (according to ISO 19106 profiles), formalised as a model (and GML schema) restriction. We are also looking right now at a formalism for the "service profile" - i.e. what makes an AWDI service useful? In the meantime, the schema, feature types, sample queries and responses represent the best description available. My understanding is that the testing framework should allow us to feed such restrictions, and conformance and robustness and performance tests can then be carried out. We would expect to feed the test suite from the formalised service profiles in the future. So its wise to have this discussion about the way aspects of those tests are packaged - its logical for them to be packaged around a concept of service profiles, that inherit from more general ones, allowing you to develop test suites and apply them to specific feature types without manually configuring each test suite for each feature type. (Thus bridging by inheritance the two view points regarding reusability of parameters vs. feature-type being bound to the tests that make sense for it) Rob -----Original Message----- From: Volker Mische [mailto:[EMAIL PROTECTED] Sent: Monday, 2 June 2008 11:00 AM To: Atkinson, Rob (CLW, Lucas Heights) Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [duckhawk-dev] Re: Configuration layout for AWDIP Hi Rob, so would these "profiles" be in case of AWDIP time and location? Some featureTypes only implement one of them, like SingleSitePhenomTimeSeries e.g. time and others like SiteSamplingStatistics both. There would be separate tests for time and location which could be run to the corresponding featureTypes. Cheers, Volker [EMAIL PROTECTED] wrote: > The underlying logic here is that services implement a "profile" of a FeatureType - i.e. they choose what to implement in regards to content rules, optional elements, cardinality, type restrictions and extensions allowed by the FeatureType. > > > Am pushing this to a wider audience because its critical to any concept of interoperability and very poorly understood AFAICT. > > Thus, parameters should be bound to the "profile" - not the FeatureType, which is one step further than Andrea's view on coupling, which is otherwise essentially correct. > > The implications, however, bring us back to the equally correct assumptions made - that these tests are repeated in slightly modified form by many FeatureType (implemented profiles). > > This is in also correct, because real Feature types inherit from more general ones. Thus, implementation profiles inherit, and the test configurations should be bound to profiles, and inherited. > > Thus, the type of time-period selections test pattern shgould be directly applicable to any feature type deriving from (or containing as a complex property) a an omx:TimeSeriesObservation (which is a specialisation of an om:Observation) - where om is the OGC Observations and MEasurements schema, and omx: is the extensions providing implementable specialisations. > > (Some of you will already be thinking about how this applies to the other aspects of tests here I expect. The content of tests is bound to the domain of the data, and this is a separate concern that follows a parallel logic - and how to model the interaction of data domain and behavioural patterns is still a work in progress) > > Rob Atkinson > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
