On 12/05/2011 05:05, Michael Neale wrote: > Is there a useful subset as "proper" XML and leave the long tail for some > catch all tag? > > I guess depends who wants this, for what purpose ;) I am guessing tooling > /GUIs mostly, with a little bit of interchange? What's in Drools 4.0 XML probably is that useful subset.
Mark > Sent from my phone. > > On 12/05/2011, at 1:57 PM, Mark Proctor<mproc...@codehaus.org> wrote: > >> if you want full 100% xml, you'll first need to define a full expression >> language in XML - as Drools DRL now supports freeform expressions. If >> someone wants to work on that first, we can see how to utilise it's >> namespace inside of patterns. >> >> Jess XML works as it's expr language is simple. Drools 4.0 worked as >> it's expression language is simpl. With drools 5.2 we now allow any free >> form expression, and thus it's not so simple. >> >> Mark >> On 11/05/2011 10:33, Pierre wrote: >>> Mark, All, >>> >>> AFAIK, xdrl is used for systems to exchange rules (perhaps for storing >>> too). This, as opposed to human use, for which XML can be quite awkward to >>> say the least. This to say that putting readability as a major factor might >>> make us miss the main point. >>> >>> For humans<expr>status == state</expr> is nicer. However, for systems >>> interaction it's pretty terrible. It's some form of half use of XML where >>> the expression itself can only be validated or transformed with >>> considerable efforts (e.g. regex) when xml tags would allow using standard >>> XML tools (e.g. XPATH). I've got examples of this in the rule translation >>> console: http://yieldrif.appspot.com/ (shameless plug!). >>> >>> Let's have a look at other XML rule descriptions (please note that I don't >>> imply that these are 100% valid expressions in their respective languages): >>> >>> JessML >>> >>> <pattern> >>> <name>Order</name> >>> <binding>o</binding> >>> <slot> >>> <name>total</name> >>> <test> >>> <type>eq</type> >>> <conjunction>and</conjunction> >>> <value type='VARIABLE'>__synth0</value> >>> </test> >>> <test> >>> <type>eq</type> >>> <conjunction>and</conjunction> >>> <funcall> >>> <name>></name> >>> <value type='VARIABLE'>__synth0</value> >>> <value type='INTEGER'>100</value> >>> </funcall> >>> </test> >>> </slot> >>> </pattern> >>> >>> RIF-PRD >>> <formula> >>> <name>Order</name> >>> <formula> >>> <Equal> >>> <left> >>> <Var>total</Var> >>> </left> >>> <right> >>> <Var>-var-__synth2</Var> >>> </right> >>> </Equal> >>> <Equal> >>> <left> >>> <Var>total</Var> >>> </left> >>> <right> >>> <Expr> >>> <op> >>> <Const >>> type="http://www.w3.org/2007/rif#iri";>http://www.w3.org/2007/rif-builtin-predicate#numeric-greater-than</Const> >>> </op> >>> <args ordered="yes"> >>> <Var>-var-__synth2</Var> >>> <Var>100</Var> >>> </args> >>> </Expr> >>> </right> >>> </Equal> >>> </formula> >>> </formula> >>> >>> I hope this helps, >>> Pierre >>> >>> ------------------------------ >>> >>> Message: 6 >>> Date: Tue, 10 May 2011 09:11:24 +0100 >>> From: Mark Proctor<mproc...@codehaus.org> >>> Subject: Re: [rules-dev] xdrl fixes/enhancements >>> To:rules-dev@lists.jboss.org >>> Message-ID:<4dc8f32c.7080...@codehaus.org> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> On 10/05/2011 09:07, Mark Proctor wrote: >>> >>>>> On 10/05/2011 08:10, Veit Guna wrote: >>>>>>> Hi. >>>>>>> >>>>>>> Any chance that this could be reviewed and maybe integrated into the >>>>>>> release? >>>>>>> >>>>>>> https://jira.jboss.org/browse/JBRULES-2672 >>>>> I'm in two minds on this. Edson and I are thinking of changing the xml >>>>> parser to just be: >>>>> <Pattern object-type="xxxx"> >>>>> <expr>......</expr> >>>>> <expr>......</expr> >>>>> <expr>......</expr> >>>>> </Pattern> >>>>> >>>>> With any valid expression allwed in expr, i.e. any combinatino of ||, >>>>> &&, method calls, +, - etc. Which follows what we've done with free-form >>>>> drl. >>>>> Our current approach to normalising expressions in XMl isn't working too >>>>> well, and the more we extropolate that the worse it gets: >>>>> <dro:pattern object-type="String"> >>>>> <dro:and-constraint-connective> >>>>> <dro:field-constraint field-name="this"> >>>>> <dro:literal-restriction evaluator="!=" value="null"/> >>>>> </dro:field-constraint> >>>>> <dro:field-constraint field-name="this.toLowerCase"> >>>>> <dro:literal-restriction evaluator="==" value="true"/> >>>>> </dro:field-constraint> >>>>> </dro:and-constraint-connective> >>>>> <dro:from> >>>>> <dro:expression>fctv_17263.getHeaderValues("X-My-Header"); >>>>> </dro:expression> >>>>> </dro:from> >>>>> </dro:pattern> >>>>> >>>>> But I do recognise that you patch might give a lifeline to existing XML >>>>> users.... >>> I should add that I ripped out most of the handler validation >>> parent/peer stuff already. This was necessary to get the new compiler >>> working, and<expr> actually already works, see DumperTest. >>> <lhs> >>> <forall> >>> <pattern object-type="State"> >>> <field-binding field-name="state" identifier="state" /> >>> </pattern> >>> >>> <pattern object-type="Person"> >>> <expr> >>> status == state >>> </expr> >>> <field-binding field-name="likes" identifier="likes" /> >>> </pattern> >>> </forall> >>> >>> </lhs> >>> >>> Mark >>> >>>>> Mark >>>>> >>>>>>> _______________________________________________ >>>>>>> rules-dev mailing list >>>>>>> rules-dev@lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> rules-dev mailing list >>>>> rules-dev@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
