RE: Efficacy of rule specification, processing

The "suggestions" are one and the same as the righthand side of "matches".

Hilarie

> > > "Yang, Lily L" <lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com> 06/15/01 
> > > 02:40PM >>>
Hilarie --
I meant, IF (a big IF) we parse the body then we would just set up a rule
saying 
<rule >
        <property name="response_body" matches="phone-number">
                <action>whatever</action>
        </property>
</rule>

The earlier version of IRML supports variables like "response_body" and
"request_body" for body parsing. But it did not have the mechanism to
suggest to the engine that it should search only at a certain level (like
only the XML tag, etc). Prior to the Minneapolis meeting the mailing list
discussed the issue of whether or not support body parsing and in the end we
removed the support of "response_body" and "request_body".

If you have several tags to search for, you can have nested rules or write
the regular expression to reflect the exact syntax you want to search for.

But I thought maybe I misunderstood your example after all, like Markus
pointed out --
"Not sure whether Hilarie refered to meta-tags in the message body. The
point was that '...services should be allowed to introduce components
that define and set variables for the rule engine.' This can be
achieved without having to parse the message bodies - for example by
supporting user-defined header fields, as in IRML."

Lily

> -----Original Message-----
> From: Hilarie Orman [mailto:HORMAN(_at_)volera(_dot_)com] 
> Sent: Friday, June 15, 2001 12:01 PM
> To: lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com 
> Cc: ietf-openproxy(_at_)imc(_dot_)org 
> Subject: RE: Efficacy of rule specification, processing
>
>
>
> By "setup a rule to find a tag", I assume you mean  
>  If content-type == html then call find-phone-number-tag
> ?
> But if you've got several kinds of tags, then you have to
> call a content-scanning routine for each one.  That kind of
> repeated scanning is exactly what the rule-centric system
> has to avoid.  The content scanning is a shared computation,
> and its results must be available to the rule engine.
>
> Hilarie
>
> > > > "Yang, Lily L" <lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com> 06/14/01 
> > > > 02:14PM >>>
> Two points regarding Hilarie's example here:
> 1) Currently IRML does not let the rule engine parse the data (like
> html/xml) itself. It only parses the html headers. The sole 
> reasoning behind
> it is for performance and simplicity. We feel like the 
> service itself would
> deal with the data, not the rule engine.
> Maybe people are not aware of that limitation. So it is good 
> time to reflect
> on it. How do people feel about that? 
> 2) IF the rule engine does parse the content, then you don't 
> really need to
> define a variable per say for the example of 
> "has-an-xml-phone-number-tag"
> -- you just set up a rule to find the <phone-number> tag in 
> the XML data
> body. Regular expression matching can easily satisfy that. No need to
> additional variable.
> Lily
>
> > -----Original Message-----
> > From: Hilarie Orman [mailto:HORMAN(_at_)volera(_dot_)com] 
> > Sent: Thursday, June 14, 2001 10:46 AM
> > To: hofmann(_at_)bell-labs(_dot_)com 
> > Cc: ietf-openproxy(_at_)imc(_dot_)org 
> > Subject: Re: Efficacy of rule specification, processing
> >
> >
> >
> > The question is, how much shared computation can be done
> > before dispatching to the individual services?   Where rules
> > have common variables, it makes sense to share.  If a common
> > variable can be introduced, through, for example, content
> > parsing, then it makes sense to expose this to the rule
> > evaluation engine.
> >
> > Now, I further claim that services should be allowed to
> > introduce components that define and set variables for
> > the rule engine.  An example is an XML parser.  That
> > should be allowed to set variables like 
> > "has-an-xml-phone-number-tag".
> >
> > Hilarie