Task List

Here are some of the outstanding tasks for the Woden project. Initially, this is just a brain dump to capture known To Do's in one place. Anyone interested in contributing to the development of Woden can start with this list to see what needs doing, however the list is not necessarily 'complete'. Contributors may identify other interesting pieces of work not listed here. Notify woden-dev@ws.apache.org if you want to take ownership of any of these tasks and update the Status section below.

This list will be updated as development progresses. Anyone can update it. As tasks are completed they should be moved from the Open Tasks list to the Closed Tasks list at the end of this page. Tasks which raise important issues or involve significant work should be raised as JIRA issues.


De-duplicating elements to objects

Ensure that duplicate elements are being de-duplicated to the same object correctly in the Woden implementation.


Not complete yet.
19Dec06: JKaputin to investigate this further to see if a JIRA is needed - will then close this task.

Obtain an ErrorReporter or ErrorLocator via the API

Provide the ability to obtain an ErrorReporter object via some type of factory method on the API to avoid the need to use new ErrorReporterImpl. This must accomodate any user configuration such as custom ErrorHandler. A problem has arisen in some Classes that are included in the API that need to report errors - they create an error reporter instance (to avoid excessive passing of object references via method args), but they must not expose any Impl classes. Hence the need for a factory mechanism. A similar requirement exists for ErrorLocator.


Not done.
19Dec06: JKaputin to investigate this further to see if a JIRA is needed - will then close this task.

Refactor XML types support into ws-commons

Woden has copied org.apache.axis.types.NCName. Per suggestion from Sanjiva, consider refactoring this types support in Axis, Axis2 and now Woden into a new ws-commons project.


Not done.
19Dec06: JKaputin to investigate to see if a JIRA is needed or whether to just close this task.

Sequencing and dependencies of Assertions

We need to look at adding some form of sequencing and dependency to the assertion tests in the validation logic, where appropriate. Some asserts should happen before others. Some asserts should not be run after previous asserts have failed.

For example, take:

If Schema-0017 assertion fails, we should not attempt Schema-0052 assertion because it becomes redundant if we already know there is no targetNamespace.


(jkaputin) A related discussion thread is currently running on woden-dev (at 25 Jan 06). Capturing the thought here so we don't lose it, but will probably raise JIRA when some conclusion is reached on the discussion.
19Dec06: JKaputin to check if this specific error still occurs and if so, open JIRA, otherwise just close this task with n.f.a.

Replace Error API Interfaces with Classes

A customized error handler is provided by implementing ErrorHandler interface. ErrorInfo, ErrorLocator and ErrorReporter are also declared as interfaces by the API. Consider whether it is ever necessary for custom implementations and if not, whether these API interfaces should be changed to final classes (i.e. they do need to be exposed on the API, but we may not want behaviour different to that provided by the Woden impl classes).


20June06 Task created.
19Dec06: JKaputin to investigate whether this is a valid issue that should be captured by JIRA, or whether just to close this task.



User documentation

Create user documentation on the woden web site explaining how to use Woden via the API. Programming model, configuration, etc. Include some code examples.


02Feb06: The User Guide now on the web site. It reflects current development. Work to expand and restructure will be ongoing.

Prototype Axis2 use of Woden

We'd like to understand how Axis2 uses WOM and how Woden fits into the picture. Some discussions on the Axis2 mailing list indicate Woden might be a replacement for WOM. Is this really the case or is the function we are aiming to provide in Woden a subset of what WOM eventually aims to provide? In which case should Woden be used within WOM? We need to understand what requirements Axis2 might have on Woden.


Done. Chathura Herath began investigating around April 06. 13 June 06, Eran Chinthaka advised end to end test is working, parsing WSDL 2.0 document into Axis2, building client/server artifacts using WSDL2Java, then sending SOAP message from client to web service.

Create more readWSDL API methods

Woden currently just has a readWSDL method that takes an WSDL location url. Other readWSDL signatures are required, similar to those in WSDL4J's reader.


Done. In M5, created WSDLSource and added reader method readWSDL(WSDLSource).

WSDL <import> and <include>

Due for Milestone 3. Implement parsing of <import> and <include> WSDL elements into the ImportElement and IncludeElement objects and abstract (flatten) this document composition structure into the properties of the top level Description component.

Add junit test cases for this functionality to the Woden test suite.


02Feb06: John Kaputin has implemented the Element parsing and component model logic, but not yet created the junit tests.
WODEN-49 raised for unit tests.

Extended Interfaces

Due for Milestone 3. Implement parsing of the extends attribute of the <interface> element and within the containing InterfaceElement object resolve the QName references to the extended InterfaceElement objects. Likewise for the Description component, resolve the extended Interface components.

Add junit test cases for this functionality to the Woden test suite.


02Feb06: Didn't make M3, will be re-targetted for M4.
20June06: Parsing of interface extensions added in M4, but junit test cases are still outstanding.
WODEN-54 captures unit tests required.

Junit tests for parsing

Due for M3. Add junit testcases to the Woden test suite for the parsing logic implemented so far for Description, Types, Interface, Binding, Documentation, Property, Feature.

Also, create junit tests for the Service and Endpoint parsing added recently for M3.


John Kaputin is working on this, but other's are welcome to contribute.
02Feb06: Unit tests completed for ServiceElement, EndpointElement (in SVN, but did not make M3 build).
Unit test reqs captured by JIRAs WODEN-49,50,51,53,54,55

element=union of xs:QName, xs:token

The element attribute of interface operation <input> and <output> can be a QName or a token. Currently just implemented as type QName. Need to model this with inheritance and change the implementation to handle either.


Implemented in M6 or earlier

Developer documentation

Create technical architecture and design documentation on the Woden web site, including alternatives, rationale, etc.


Not done. John Kaputin should probably start this.
21Nov06 need to create JIRA(s) for the documentation required then close this task
19Dec06 captured this as JIRA WODEN-111 and removed this entry from wiki tasklist.

Use Cases

Documented use cases covering the various usage scenarios for Woden would help to clarify our collective understanding of the total requirements to be met by Woden and why certain design or implementation choices are necessary. So far, development has focussed on parsing and validation (i.e. read-only at runtime), but we need a better understanding of the WSDL creation / editing / writing requirements (e.g. re-validation after modification, preserving whitespace, etc).


Initial attempts at identifying actors and use cases by John Kaputin and Jeremy Hughes. Will post work-in-progress to wiki or web site when we have something documented. Will need broader input from others on this.
19Dec06: captured as JIRA WODEN-112 and closed this task.

Message label

The messageLabel attribute of the message reference or fault reference elements is currently implemented as a type-safe enumeration with the values 'In' and 'Out'. This needs to be implemented either as an extensible enum or perhaps just as an NCName.

Arthur: I believe the correct design is to simply use NCName since that is the type of the {message label} property in the WSDL 2.0 component model. The checks for allowed values of {message label} should be handled by the MEP. Woden should be extensible wrt MEPs.


Not done yet.
This has been done - message label is now represented as an NCName.

Parse constraint attribute of <property> as type QName

the constraint property of the Property component may contain either a QName or the token '#value', however in its XML representation, the constraint attribute of <property> is of type QName only. Need to change the parsing logic in reader.parseProperty so that it does not allow for '#value' in the XML.


Not done.
Property now removed from WSDL 2.0 spec and from Woden.

Line / column nos. in Error Info

Need to implement the capture of the source line and column numbers for WSDL parse-time errors. Currently, the ErrorInfo object provides this information, but it is just initialized to zeroes. For the DOM implementation of Woden, maybe consider subclassing the SAX parser object and extending it to capture this information during parsing. Perhaps stored in a separate collection, keyed by element qname.


Not done.
Captured as JIRA WODEN-113.

XML Catalog resolver

Add catalog resolver capability to Woden to resolve alias URLs to physical documents. Some of the W3C test suite test cases require this capability and are currently failing.


Not done.
19Dec06: a simple resolver has been implemented, an Oasis Catalog is to follow soon.

Consider Typed Collection classes

The Woden API currently uses typed arrays to provide typesafe collections of objects. A concern was raised previously about this limiting the implementation choices for collections of objects. Consider replacing typed arrays with Woden-specific typed collection classes that hide the array implementation and maybe offer Collection or List style, typesafe accessor methods.


Not done. Closed - this will come up during API review prior to 1.0

Dereferencing objects from a 'master' collection

Woden implementation mostly has objects dereferenced from QNames, etc, stored directly within their containing WSDL objects (one exception is schema elements and types which are dereferenced dynamically from ElementDeclaration, TypeDefinition, etc, via TypesImpl). Consider using an implementation similar to the XmlSchemaCollection class in ws-commons XmlSchema, that maintains a global collection of WSDL objects that are dereferenced dynamically when access is required. In this case, it is only the key (e.g. QName) that is stored in the containing WSDL object. This might make it easier to support the WSDL creation and editing use cases.


Not done.
19Dec06: Woden impl has now been changed to dynamically dereference qnames within the model.

Update object refs if WSDL object model changes

Ensure that cached or dereferenced objects are cleared or modified if the WSDL object model is changed. The task above to consider using a global collection of dereferenceable WSDL objects might help with this.


Not done.
19Dec06: Closed for now. will be considered when update capability is added to the component model.

Refactor Component builder logic

The ComponentBuilder class is used to populate properties of the WSDL Component model from the Element model when the toComponent() method is called on the DescriptionElement. Some of this behaviour is also present in the parseXXXX methods in WSDLReader because it's easier to handle this at parse-time when we have the necessary object references. Consider eliminating the ComponentBuilder class by refactoring its logic, maybe directly into the Impl classes.


Not done.
19Dec06: done in a previous milestone release (still some extensions code to be refactored)

General type system support

Woden currently supports just the XML Schema type system. As per the WSDL 2.0 spec, some form of more general, extendible type system support is required to cater for non-XML Schema type systems.


Not done.
19Dec06: replaced by JIRA WODEN-114.

Improve the API javadoc

Much of the javadoc for the interfaces and classes that comprise the Woden API is out of date, incomplete or insufficient. This needs to be addressed.


In progress by John Kaputin. Will provide more focus for M3.
19Dec06: has been improved. Ongoing work required, but no need to keep task open.

ws-commons XmlSchema

More testing is required of XmlSchema. There are a few outstanding errors in the W3C WSDL 2.0 test suite due to known limitations with XmlSchema. It's what is not known that is more of a concern. Really requires some effort to create and contribute more test cases to the ws-commons XmlSchema test suite.

Also need to consider how we can eliminate the XmlSchema implementation from the Woden API. Maybe by providing Woden interfaces that wrap the XmlSchema classes that are used by the Woden API. Or maybe a better solution is to separate XmlSchema into an API and an implementation, but that's considerably more work that requires involvement/approval from Apache WS, not just the Woden team.


Not done.
19Dec06: quality of XmlSchema improved over recent releases. No plans now to hide XmlSchema in Woden API.

Add QName lookup methods to Description

WSDL spec Part 1, 2.19 QName Resolution describes looking up top level components like Interface by their QName within the Description component. The org.apache.woden.wsdl20.Description interface currently has collection methods like getInterfaces(). It also needs getters that take a QName arg like getInterface(QName). Ditto for Binding and Service.


Not done.
19Dec06: done in a previous milestone release.

Mavenize Woden

Use Maven2 to build Woden and have Woden binaries posted to ibiblio so that other maven based projects can consume Woden


Not done.
19Dec06: captured by WODEN-67


FrontPage/Woden/TaskList (last edited 2011-06-10 12:03:24 by 124)