• version 0.1.x
    • Fixing important issues (design and code : see the todo list below).
  • version 0.2.0
    • Design and implementation of Active Catalog.
  • version 0.2.x
    • Fixing important issues (still in progress).
  • version 0.3.0
    • Alignment with INRIA's namespace server with other enhancements that will break the compatibility with previous versions. Group with other cleanings that don't preserve the compatibility.
  • version 0.3.x, 0.4.x
    • Fixing important issues (still in progress).
  • version 0.5.0
    • Moving to Java 6 (...or 7).
  • version 0.6.0
    • Full implementation of Active Schema and data types (0.3.x).
  • version 0.x
    • The engine is complete. Changing status from "beta" to "release-candidate", then from "release-candidate" to "stable".
  • version 1.0.0
    • The engine is complete.


A very long list...

  • Active Tags / core :
    • check active sheet with schemata
    • refactor the context feeder (this is a feature to move to AbstractAction)
    • define the dynamic content models in the specifications
    • plug a logger
    • make serializers : XSLFO to PDF (move to a more recent version of FOP), SVG to raster formats (Batik), pretty XML printer, HTML serializer, etc. Use the same machinery as those used for built-in (hard-coded) filters ?
    • shortcut for <foo:bar/>{.} -> {<foo:bar/>}
    • make a wrapper for RuntimeException : a transparent exception that can be unwrapped safely (the wrapped exception could be propagated) ; needed when the possible exceptions are not suitable ; more reliable for pattern matching in fallback actions (see below).
    • allow to unmarshal active sheets with SAX / release DOM nodes (free memory).
    • "Acquisition" : some components could understand some of their parameters as attributes ; if the name of a parameter is an XML name, why not accept an attribute instead of a parameter ? Example : <xcl:parse-filter name="myFilter" pattern="[regexp]" buffer="1024" source=""/>
  • Active Update :
    • refactor XOperator
    • allowing content updates of X-operable objects from a regular XML fragment ?
    • check if "XQuery update facility" could help, as it is a more formal approach.
  • XCL :
  • EXP :
    • ability to call logic procedures from another PI (change <xcl:call logic="QName"> with <xcl:call logic="expression"> where the expression is evaluated in the context of X-processor-instance which children are actions)
    • can set the arity of the function definitions in <exp:function>.
    • can specify the types allowed in functions and active tags.
  • Active Schema :
    • implement the remaining WXS data types
    • design point : element structures and classes
    • clean type support
    • implement the delegative model
    • MSV integration ; I'm not sure about this point : perhaps ASL is the right entry point for other schemata, including DTDs. DTDs could be mimicked in ASL with few efforts, even when parameters entities are used and some stuff redefined in the internal subset.
    • populate schemata of each module
    • format error messages : this is urgent to make ASL really usable !
    • pattern matching on <asl:element> : @match="..." ; this might cause issues when selecting the element definition if a schema is overriden : which one is the good one ? what is the strategy ? Do the same for attributes.
    • TypeAction, type() -> several types
    • design a "templater" (<asl:templater>) : from a schema, one build a minimal XML document that statisfies it partially (fill mandatory stuff, not those for which a choice must be done) or fully (use the first choices). Make an option to indicates what to do with attributes.
    • Error : redesign properties ; @path is sometimes on the host element, sometimes on the last, whereas it should be the host element ; additionally, the candidate could point to the erroneous node, and maybe the previous sibling should also be set as a property.
    • it appears that having @min-occurs > @max-occurs is not an error : it denotes that some conditions are not satisfied and can be corrected by many different actions (add or delete an element, but don't keep the number of occurrences as-is ; the message would be : asl:invalidOccurrenceNumber). Note that this applies on dynamic boundaries : hard-coded values should still raise an error.
  • Active Catalog :
    • implement more active tags
    • design point : caching policies
    • builders : how to use builders for example with XSLT ?
    • builders : builder of builders
    • mapping OASIS catalog to Active Catalog : the XML source is lost, as the oasis:* elements are translated to cat:* elements, which makes the canonical path irrelevant ; this is worst for plain-text catalogs that don't have an XML source !!!
  • RDBMS module : this is a very basic and minimal implementation
    • implement Active Update support
    • implement batch requests
    • fix grouping issues : when xcl:group() is involved, the entire result set is copied in a list (see TODO:IMPORTANT) :(
  • I/O module :
    • do not use URI with io:resolve-uri() : a path can't be resolved on a base URI when schemes are wrapped because they become opaque URIs ; use VFS instead
    • there are issues with VFS, as it doesn't set the type of files to directory if they end with "/", which cause troubles when resolving paths
    • use a thread dependant FileSystemOption for helping web and res schemes resolution. This is necessary to allow RefleX installation in $TOMCAT/shared/lib. For the moment, only the web scheme can be used if RefleX is installed in $TOMCAT/shared/lib.
    • make a text matcher/replacer.
    • define the @io:input for the #io:x-file type, that return either an input stream or a reader according to the explicit encoding, or to those guessed from the content, or those of the platform. @io:output would endorsed the encoding specified explicitely.
  • Web module :
    • fix bug : forwarding with additional query parameters cause troubles
  • XInclude, some options :
    • the includer works for DOM into DOM, SAX into SAX, but what about a user option for including SAX into DOM or DOM into SAX ? @style="[tree|stream]" (default is unchanged)
    • @root-base="[omit|relative|absolute]" : what to do with the @xml:base attribute on the root ?
    • @mode="[strict|lax]" : allow fragments inclusion
    • Options are only parameters (<xcl:param>), they also could be attributes on <xcl:parse-filter>
  • Java :
    • FIXME : refer to the source code
    • TODO : refer to the source code
    • IMPORTANT : refer to the source code ; it means "urgent" :(
    • Dynamic list : the size should be actualized when hasNext() is invoked. This is not the case with XML:DB results.
    • Stack trace : display once with the higher canonical path that causes the error.
    • Unmarshal : automation can be achieved when Active Schema will be completed. This is the Active Data binding, that will be available in RefleX 2.0
    • Bootstrap sequence : the primal catalog should not be hard-coded, but parsed from res:///org/inria/ns/reflex/catalog.xml ; define an option in the CLI and the servlet that allow the user to specify another one.
    • CLI : allow to run an active tag directly.
  • Modules :
  • Externals :
    • Support of Javascript
    • Support of Java (compilation/CL)
    • Clipsable to Eclipse
  • Import in this list the items from the primal ToDo list


Refactoring Ant

A couple of years ago, I gave to my students a project that were using RefleX and Active Tags. They had to refactor Ant with Active Tags : the underlying objectives were to dive into XML with Java, to deal with unmarshalling issues, and of course to design a smart new module for Active Tags. Of course, I didn't ask them to cover the entire Ant spectrum, just to refactor few tags : <project>, <task>, <javac>, <javadoc>, <jar>, <war> and that's all. But some stuffs were different from the real Ant : for example, file sets were available in Active Tags thanks to XPath expressions, so, IMHO, there were much things easier to implement with RefleX than without RefleX.

The REST module

Ideas about integration with the Restlet project : a Java API that allows to make Web applications in the REST fashion. Why not designing a REST module with this API ?

Testing Web application kinematic with XUnit

The 0.2.0 version has introduced XUnit, a framework for testing XML-based applications (Active Tags applications, XSLT applications, or others).

XUnit is invokable from the command line to test batch processes or standalone components that could be involved in a Web application, but it is not trivial to test the kinematic of Web applications with XUnit, for example to check that the objects stored in a session are available page after page.

What is expected is a kind of rewritting of the Web module that would be available in a batch mode, in order to submit HTTP requests and check HTTP responses with XUnit. Maybe something based on Jetty ?

I asked to my students to build a module for Web testing with XUnit ; the challenge was to NOT rely on a servlet engine but to mimick one in batch mode. Fun !

→ The 0.3.1 version has introduced WUnit, that addresses this issue somewhat efficiently and elegantly : there is both a client and a server that can discuss without network connexions in order to be able to get server-side objects like session and act on them during the test. The client-side support Javascript and AJAX applications can be also tested.