deegree3 developer meeting (2008-09-15)
Protocol by: RutgerBezema
Participants: OliverTonnhofer, ChristianKiehle, RutgerBezema, AndreasPoth, MarkusSchneider
Contents
1. Status reports
- Work in process, delayed because of project work.
- It is possible to bind an arbitrary xml schema (not gml specific) to the feature type definitions.
- Loading of complex xml instance documents (imro) works.
- Geometries are not supported yet.
- A tool for the analysis of profiles based on xml-schemas is available.
- OGC profile 1.0.0 compliant. Team-engine (cite) tests succeed.
Work on the definition of a DataSource configuration is still to be done.
- Database definitions should be clarified.
2. Axiom bug
While doing the SOS-cite test for d3, a grave bug in the axiom implementation has been noticed. When an invalid document (e.g. a missing NS-binding) is parsed, axiom does not notify the caller with an exception. It will return a DOM tree that misses all nodes of the document that appear after the erroneous one. The missing nodes will result in misleading exceptions when issuing XPath expression on the tree (i.e. required nodes are missing even though they are in the input document). Although a bug has been reported (to axiom) about this issue half a year ago, no fix has been created. No reply was given on email requests about this issue. Maybe the Apache foundation should be notified about this bug. Two approaches to bypass this behaviour were proposed:
- Use StAX as the default parser:
- pro: Fast parsing, (and obviously avoidance of above bug)
- contra: loss of XPath evaluation and the complexity of writing the parsers.
- If a missing element is found, the XML-instance should be validated against the schema
- pro: all advantage of DOM, (and obviously avoidance of above bug)
- contra: all schemas need to be available, slow.
3. Versioning of services configuration files
As described in configuration of webservices 5.1 the question of whether to use a versioning attribute or a versioned namespace for all configurations was discussed. A negative affect of placing the version in the namespace is the overhead caused by minor (optional) updates to the configuration. The usage of a version attribute could entangle the configuration files.
It was brought forward that the global configuration file for d3 webservices should not be called metadata.xml because of probable confusion with CSW terminology. Also it was suggested, that all configuration schemas should be available on a http server.
4. Functional requirements
Because a lot of substystems still have no hard requirements defined, it was suggested, that all deegree2 module administrators should write down a list of currently available functionalities in deegree2. After that, currently unfulfilled customer requirements should be taken into consideration and compared to the deegree2 functionality.
The result should be a good starting point to decide d3 requirements.
5. Security
A first draft of the functional requirements for the security subsystem was written by AndreasPoth. It was uttered that, because of project specific demands, the implementation of this subsystem will be postponed until more details about the requirements are specified.