Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by JohnKaputin: http://wiki.apache.org/ws/FrontPage/Woden/TaskList The comment on the change is: Created an initial task list capturing some of the outstanding woden tasks. New page: = 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 [email protected] 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. Tasks can be removed as they are completed. Tasks which raise important issues or involve significant work should be raised as JIRA issues. ----- == 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. ==== Status: ==== Not started. John Kaputin expecting to do this. ----- == 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. ==== Status: ==== Not started. John Kaputin expecting to do this. ----- == 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. ==== Status ==== Not done. John Kaputin expecting to do this. ----- == 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. ==== Status ==== Not done. John Kaputin should probably start this. ----- == Developer documentation == Create technical architecture and design documentation on the Woden web site, including alternatives, rationale, etc. ==== Status ==== Not done. John Kaputin should probably start this. ----- == 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). ==== Status ==== 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. ----- == 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. ==== Status ==== Not started. ----- == 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. ==== Status ==== Not done yet. ----- == 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. ==== Status ==== Not done. ----- == 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. ==== Status ==== Not done. ----- == 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. ==== Status ==== Not done. ----- == 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. ==== Status ==== Not done. ----- == 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. ==== Status ==== Not done. ----- == 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 dereferencable WSDL objects might help with this. ==== Status ==== Not done. ----- == De-duplicating elements to objects == Ensure that duplicate elements are being de-duplicated to the same object correctly in the Woden implementation. ==== Status ==== Not complete yet. ----- == 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. ==== Status ==== Not done. ----- == 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}}}. ==== Status ==== Not done. ----- == 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. ==== Status ==== Not done. ----- == 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. ==== Status ==== Not done. ----- == 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. ==== Status ==== In progress by John Kaputin. Will provide more focus for M3. ----- == 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 XmlSchema limitations. It's what is not known that is more of a concern. Really requires some effort to create XmlSchema test cases and contribute these to a 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. ==== Status ==== Not done. ----- == 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. ==== Status ==== Not done. ----- == END of Task List ==
