Version 18

    Simulated Property Accessors

    Drools uses pojos for all field accessors. This means xml documents must first be transformed before use. Support should be added to provide bean like access to "soft" data structures such as Element Doms'

    The first aspect is to allow the type and the property accessors to     be dynamically defined
    declare Element
         @type( nodeName )
         @property( get( $1 ) )
    end

    Where $1 is the interpolation point for the passed property name.     That would then allow access to Dom Elements as though they were     natural facts. Same can be done for Maps, or similar constructs
    declare Map
         @type( get( "type" )  //the type is a key in the Map
         @propert( get( $1 ) )
    end

    declare MyFact
         @type( type ) //The type is field
         @property( getProperty( $1 ) ) // all properties are via this     getter
    end

    If you look at the expiremental FactTemplates you can see the guts     of how fields are accessed and figure out how to plumb this all up.     Then there is the RHS, which is a big more difficult, if you want the properties supported as named fields, and not emulated getters.

     

    The other issue is Drools is currently a strictly typed language, so we'll also need to support dynamic types. While we should support dynamic typing, it would be good if the user could also declare the known fields and type for a given dynamic bean.

    declare MyFact
         @type( type ) //The type is field
         @property( getProperty( $1 ) ) // all properties are via this     getter

         String : name

         int : age

    end

    The above means that we know it's a dynamic bean, but we also know the type of the properties at build time.

     

    STAX Parser Support

    Fast Content Based Routing tries to avoid doing full DOM readings when doing decision making, STAX achieves this by emitting events intead of building up a large DOM Document. Using the "Simulated Property Accessors" technique to make Elements appear as Facts, it should also be possible to have those Elements emitted into Drools, which only holds onto Elements which form part of a decision to be made. This would allow one offf reasoning to be done, based on a single parse of an XML document, without transform it into a DOM. This would provide very powerful and fast intelligent CBR. SXC http://sxc.codehaus.org/Drools tries to do something similar, but it doesn't use Drools for the reasoning, instead use a "string" XPATH and just using Drools when that pattern is selected, the idea here is to use move of Drools for the reasoning.

     

    Left and Right Unlinking

    In an effort to help encourage those thinking of learning more about the   internals of rule engines. I have made a document on implementating   left and right unlinking. I describe the initial paper in terms relevant   to Drools users, and then how that can be implemented in Drools and a   series of enhancements over the original paper. The task is actually   surprisingly simple and you only need to learn a very small part of the   Drools implementation to do it, as such it's a great getting started   task. For really large stateful systems of hundreds or even thousands of   rules and hundreds of thousands of facts it should save significant   amounts of memory.

    http://blog.athico.com/2010/08/left-and-right-unlinking-community.html