Edson, doesn't have to be line based, thats just the way it worked now cause it made it easier to expand. It *will* need to work with the IDE of course - which at the moment is kind of mixed up with the regular DRL editor (so it gets content suggestions from the DSL if it is using one). Kris wants to seperate out the DSL aware editor from the vanilla DRL one (so its less of a mess) as well - so keep that in mind. Some other requirements: * Errors when expanding should be accumulated in an error list, like the normal parser * Should be able to allow/disallow "in line DRL" expressions (ie you may want to stop people from doing something that is regular DRL, and restrict it to DSL sentences only * Error messages should be "friendlier" - as in "The sentence [....] is not understood. Perhaps you mean't [... nearest match from the DSL expressions ...]" - if possible (would be nice !) * DSL should work on whole drl files (as now) but *also* files which are just one rule (in which case the package context comes from outside the file, including the DSL etc). It may be desirable in this case to skip the "end" as it is not needed (and looks out of place in a natural type scenario - also the "rule XYZ" could be optional if the API tells the expander the rule name, which may be the file name etc). Does all that make sense? Michael. On 2/5/07, Edson Tirelli <tirelli(a)post.com&gt; wrote: