The following is a list of items that need to be completed in Jelly. Contributions are welcome!.

• write a Cocoon JellyGenerator so that Jelly scripts can be used easily inside Cocoon
• consider implementing a Jelly Doclet so that Jelly can be used to code generate stuff from javadoc tags in a similar way to XDoclet but making use of the JSTL tags and the Velocity like expression language (Jexl) which will avoid the need to use huge numbers of tags.
• Rename the DynaTag interface to be DynamicAttributes along with JSP1.3, also add a namespace URI parameter
• Add support for namespace URI use inside XPath expressions.
• When defining new tags using <define:tag>, we should allow attributes to be named,
  specified as required, specify the optional conditions and so forth for validating instances.
  I guess this could just be normal script though.
• The org.apache.commons.jelly.impl package doesn't have a great name -
  Can we think of a better one?
  Also some of the classes in this package could maybe do with a rename?
  ScriptBlock for example - should we just call it a Block or maybe a CompositeScript?
• Add parent Context and support for other scopes such as session,
  request, cookie, initParam, param etc.
  Maybe add a Scope class for variable names which can contain a scope name
  and variable name. Then things like cookie:foo or initParam:bar can be parsed
  at compile time into an object.
  
• Add an adapter to run JSP tag libraries inside Jelly when Jelly is used in a Servlet / JSP environment?
• Document much more!

• Add JUnit tag library along these lines...

  <junit:assert test="${foo == 22}">some description</junit:assert>
  <junit:assertEquals value="${foo}" expected="${22}">some description</junit:assert>
  

• An XSD tag library that can be used to parse XSD documents and create DynaBeans from the complex types.

  <xsd:element name="MyDynamicClass">
    <xsd:complexType>
    	...
    </xsd:complexType>
  </xsd:element>

  Also we could consider using class names or XSD type names to do conversions of values, maybe using the ConvertUtils class in beanutils.
• conside a tag library which implements the STX specification for the SAX based transformation of XML. This is kinda like XPath and XSLT but is based purely on a SAX stream. Maybe we could wrap Joost in a Jelly tag library
• Develop a http tag library, probably based on commons-httpclient, that can be used for scripting web services
• A Betwixt tag library to make it easy to serialize beans to and from XML from within Jelly scripts.
• Implement a Schematron tag library for validing XML using a path based approach, rather than schema based.
• Provide support for running a piece of Jelly script remotely. This would be particularly useful for distributed testing. Maybe integrating or enhancing something like rant

• Add JSL test cases to test for ordering of patterns and that the correct output comes out.

The following is a list of things that might be good to add to Jelly, maybe after more thought.

• maybe consider a tag which will switch the default EL to XPath; then XPath and EL can be peers. Then ${foo} can be used as an XPath expression anywhere
• We could autogenerate XML Schemas or RelaxNG docs for tag libraries to help validate scripts
• Patch TagLibrary to alias all <mixedCase> tags to <mixed-case> tags
• Provide an alternative non-XML parser such that Jelly scripts do not
  need to be XML. This could allow Velocity-style concise notation
  for common Jelly tags.