On 15/12/2010 09:38, Wolfgang Laun wrote:
Constraining the scope of applicable when-fragment might be added on
top of the current DSL syntax, providing a compatible migration path.
Notice that constraining the scope is similar to the rule attribute
"auto-focus", but unqualified entries may have to remain active
throughout.
Expansion will have to be able to handle insertions not only for the
last preceding pattern but also to other parenthesized condition
phrases, e.g. eval, forall, etc.
Previously DSLs had tried to look like natural
text, even in a text
file, with DRL freely mixed in. But I think most people who are using
DSLs would probably use them with tooling ontop, such as the guided
editor. As such I think it's ok to separate DSL and DRL, and maybe use
more control characters if it makes things easier. So the idea that a
DRL and DSL can be interchanged freely and almost invisibly in the same
file does not need to be dogma - going forward we need to do what is
best to keep the two approaches maintainable and extensible.
I'd even be tempted to say that DSLs could use a complete different
underlying language, such as lisp or some other document centric
language, becaus the tooling can always re-present that in a user
friendly way. Just some food for thought :)
Mark
-W
On 15 December 2010 10:18, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
Thought I'd mention where I'd like to see DSLs go in the future,
if anyone is interested. DSLs are template fragments that can be
used in conjuction with each other. I'll refer to them as template
fragments from now on.
-Selecting one template fragment constraints which peer fragments
may be used after it.
-Template fragments may have nested template fragments. The
available nested fragments are themselves constrained and
depending on which child fragment is chosen cosntrains any allowed
peer child fragments.
-As well as constraining which peer or child fragments can be used
cardinality can also be constrained.
-The peering and nesting itself can be recursively applied,
So what we are talking about here is something that is almost xsd
schema like, for producing constrained documents.
Mark
On 15/12/2010 07:41, Wolfgang Laun wrote:
> On 13 December 2010 19:58, Edson Tirelli <ed.tirelli(a)gmail.com
> <mailto:ed.tirelli@gmail.com>> wrote:
>
> Hi Wolfgang,
>
> Mark said you would like us to take a look at some of your
> commits?
> Can you let me know which ones?
>
>
> Hi Edson,
>
> I have reached a state where I think changes might be committed -
> see the attached README. I'll just go through the code and add
> some comments and make sure no "noise" remains. Then I'll send
> you the zipped tarball of all changes. If there are no
> objections, I'll also commit, but I need to do this before the
> git change incapacitates me. (I just don't have the time right
> now for making this conversion, and I won't have it until
> E12/2010. Worst time of the year for doing a change like that!)
>
> @developers: Anybody interested in this set of changes can ask me
> for the sources.
>
> Best
> Wolfgang
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev