"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Geoserver Development Iteration 2008Apr2

Ends Friday 9 May 2008.

See also:

Goals

  • Complete automated test tool {wfs.test.automation} {wfs.response.validation} AUS-253.
    • The tool is under development.
    • The tool makes a WFS post request, retrieves the response, and uses the Xerces-2 SAXParser to schema-validate it against the profile wrapper schema (the same wrapper used to configure GeoServer).
    • The tool has been used to ensure gsml:MappedFeaturePropertyfile is schema-valid.
    • The tool is in a prototype state and not fit for human consumption. Requires 3-4 days work.
    • Is validation of response content also required? If so there are more questions:
      • Are features expected to be returned in the same order?
      • Are external references stable?
      • More questions to do with the semantics of comparing response documents for equality ...
  • Expand suite to include full schema-valid use case mappings backed by property files for more use cases.
    • The first use cases to be implemented:
      • gsml:MappedFeature for use case 2A {use.case.2.a} AUS-353.
      • gsml:MappedFeature for use case 2B {use.case.2.b} AUS-354.
      • gsml:MappedFeature for use case 2C {use.case.2.c} AUS-355.
    • What will be the process for agreeing when a use case is implemented?
      • Is it sufficient to have a schema valid response?
      • What are the user-acceptance criteria that we use to determine when a use case is sufficiently covered that it is complete?
    • More test data will be required if it is necessary to test inline objects. Given the problems encountered with encoding shapes, we should get more test data and see what breaks.
    • Still not clear which instance documents correspond to which use cases.
    • Need more information.
    • Need to finish all of use case 2 before we move on to use case 3 (queries).
  • [Added 2008-04-28] Review functions in WFS filters and estimate work required.

Deferred (things we decided to not do this iteration)

  • Support for function in filter in WFS request {wfs.filter.function}.
    • Needed for use case 3 (queries)?
    • Requirement is for WFS request containing a filter to support a (CQL?) function in the filter.
      • Ben does not know anything about filters or filters-containing-functions. There will be a learning curve.
      • Need to clarify if the function can contain CQL.
      • How different is this functionality from that for simple features in GeoServer 1.5.4?
      • It is not clear if the function should be executed on the database server or on the WFS server.
      • If functions are database-side:
        • How does the function get translated across the feature mapping?
        • How is the function capability published?
      • If functions are WFS server side, filtering will be slower and more memory bound.
    • This is one of the largest technical risks of the requirements. It is potentially a large and complicated task, and hard to estimate.
      • The risk can be used as an argument to work on this now, if failure to meet this goal is a show stopper, because the sooner we start, the sooner we will know if we are likely to meet complete this task.
      • The risk can be used as and argument to defer this task, because working on it will absorb time that could instead be spent on lower-hanging fruit (i.e. the use case mappings not requiring filter functions).

Outcomes

  • Working automated schema-validation tool XmlServiceTester has been used to make all feature types in the geoserver-gsmltb3-config suite schema-valid.
  • No test cases implemented.
  • Review of functions in filters resulted in estimate of 20 working days.
Topic revision: r8 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).