Hi, this is a status update of the Castor Pull Mapping gsoc project: Process:
My gsoc mentor Joachim Grüneis and I discussed how we should carry out the project design and implementation and we decided to organize the project in iterations. We'll meet on a regular basis where we will discuss the outcome of the last iteration, and define the content of the next iteration. Finished Activities: x) To make sure we dont't implement functionality that already exists elsewhere I researched if there is a project that would allow to process a xml document, allow to locate the elements of interest and pull them from the xml stream. Requirements: * use a common used method to locate the Elements * process the xml document as stream as the whole idea revolves around saving resources We found that JAXP would provide this functionality, bus it operates on DOM only which would work against the original idea to process the xml junk by junk. http://www.ibm.com/developerworks/library/x-javaxpathapi.html http://www.onjava.com/pub/a/onjava/2005/01/12/xpath.html We didn'd find a project that supports all requirements. x) We discussed which method should be used to locate the xml fragments that shall be unmarshalled. Requirements: * don't invent a new syntax * ease of use * well known We decided to use the XPath syntax to locate the xml fragments x) We researched if we can use the XPath compiler from JAXP to handle XPath. This is not applicable because it operates on the DOM tree only. Planned activities: x) As full XPath support is not feasible within the scope of the project, we will specify the supported XPath subset. http://www.w3.org/TR/xpath x) Implementation of the Xpath compiler incl. test cases for the use within our project (there is no XPath compiler we can use) x) Research what's the best way to feed the xml junks into castor xml mapping No worries, Bernhard
