[rules-dev] quick design questions to mull over - regarding the repo

[Michael Neale]

I think I will make DSL an "asset" - but there will by default be only one
(like Highlander - "there can be only one") - that will be the one used
unless there are multiple in which case you would have to specify which one
to use.

Model I will do the same.

The NEXT question is: One model (versioned) or multiple files? I spose
multiple files are also doable as well....

On 2/2/07, Edson Tirelli <tirelli at post.com> wrote:
>
>
>     Answering Michael, I agree with Felipe on Q2, but on Q1, I would
> like to note that I think it would be good to allow for more than one
> DSL in the future. This way, we would be able to create DSLs associated
> with "partitions" of the business model, and for each ruleset, we would
> use the DSLs associated with each partition we are using. Ok, the
> explanation is messy, so let me tell about an eventual use case:
>
>     In a telecom market, we possibly would have a Customer Business
> Model (with customer related info), a Telecom Service Business Model
> (with service related info, like calls, service plans, etc) and a
> Finance Business Model (with billing related info, like charges,
> discounts, etc). So, a Billing system would use the Telecom Service
> Business Model and Finance Business Model, while a Customer Self-Service
> System might use the Telecom Service and Customer Business Model, while
> the CRM would use all of them.
>     As the DSL usually translate to Patterns and Constraints of the
> mapped business model, and actions related to that, it would be good
> from a reuse perspective to allow the use of multiple DSLs in each
> context.
>     So, IMO, we should be prepared to support multiple DSL's for a
> single rulebase/drl soon. If that mean the DSL must be assets instead of
> attribute, I would go for it.
>
>     Just my 0.02.
>
>    []s
>    Edson
>
>
>
> Felipe Piccolini wrote:
>
> > Hi Michael,
> >
> >   Iv been following your work in the brms/repository very closely
> > because Im working in something very similar by
> > my self for a project using JBossRules, and as I cant wait much longer
> > I decided to use your work as a base to
> > put something on production until you guys do the "real-cool" thing.
> >
> >   About your questions, IMHO,
> > -Q1: I think dsl should be an attribute (as far as I know, you can put
> > only 1 dsl expander on drl files) and
> > there should be only one reference to expand the rule sentences, if
> > you have multiple dsl, then have mutiple drl (packages).
> > -Q2: I think object models (or business models to use as facts for
> > your rules) should be assets, so u can organize your model/classes
> > not thinking in drools or any other framework, so you can extend your
> > model or rules with just a pointer as a dependency, just as you
> > can put or remove jars from your classpath.
> >
> >  One thing I wanted to tell you for some time about drools-brms is
> > that for some reason I dont know, the gwt ui looks awfull on mac (OS X),
> > I made it works changing some things on the .launcher and .shell
> > files, but its looks like no modal window has a background, or complete
> > messed up.. can you check it out? or help me to guiding me what to
> > check to see it right? Thanks.
> >
> >
> > On 01-02-2007, at 3:23, Michael Neale wrote:
> >
> >> BUT this also applies to the file structure for "packages" in a file
> >> system/IDE (forget monolothic DRL for a moment - but instead imagine
> >> a folder which is a rule package containing lots of rules).
> >>
> >> (in no particular order);
> >>
> >> Q1: Should DSL "language configurations" be stored as an "asset"
> >> inside a package (ie a file, perhaps multiple ones of them?) - or are
> >> they an attribute of a package?
> >> Q2: The object model: should this be stored as an attribute of a
> >> package - or just another asset of which there can be muliple ones
> >> uploaded (as a jar, for instance).
> >> This is needed for validation/tooling. Obviously in the IDE the
> >> classes will be on the classpath, but in the repo they have to be
> >> stored somewhere.
> >>
> >> Note versioning works well in all scenarios (subtle differences
> >> between a package attribute and asset for versioning, but ignore them
> >> for now).
> >>
> >> I have opinions, but wanted some discussion (attachment screenshot
> >> shows the package managment screen).
> >> <Screenshot-JBoss Business Rules Management System .png>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> > *Felipe Piccolini M.*
> > felipe.piccolini at bluesoft.cl <mailto:felipe.piccolini at bluesoft.cl>
> >
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >rules-dev mailing list
> >rules-dev at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3124-6000
> Mobile: +55 11 9218-4151
> JBoss, a division of Red Hat @ www.jboss.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070202/0cb5b6c4/attachment.html