Subject: RE: moving along on rules language

From: Alex Rousskov <[email-masked]>
Date: Thu, 11 Sep 2003 08:48:39 -0600 (MDT)

-- Posted on behalf of Anwar M. Haneef <[email-masked]>

	---------- Forwarded message ----------
	Date: Wed, 10 Sep 2003 13:45:54 -0500
	From: Anwar M. Haneef <[email-masked]>
	To: [email-masked]
	Subject: RE: moving along on rules language

I haven't been an active participant on this list, but have worked on
OPES for a while (2 years) from an academic standpoint. I agree with
Andre regarding the compactness of the rule expression language. The
reason for this is because I don't see the need for these rules to be
interepreted on the fly. A more realistic scenario from my perspective
would be an intermediary pulling out pre-interpreted rules that are
stored in 'bytecode' native to an intermediary at the processing
points. This would reduce the processing overhead at the intermediary
since the pre-processing and archiving of processing point rules could
be done offline.

On the other hand, Alex's proposed P language seems to entertain a
more flexible mechanism for expressing expressions. Maybe this is due
to my lack of experience in languages, but this is one major issue I
had with developing IRML-based Processing Point rules for content
delivery based on QoS and device characteristics. My Master's Thesis
on an OPES-based approach for content delivery for heterogeneous
multi-deviced user environments is accessible at:
http://anwarhaneef.home.comcast.net/publications/publications.htm#thesis
for those who might be interested.

Another concern I had regarding P is the relative ease or complexity
of auto-generation P language rules. For instance, from my previous
experience (mentioned above), it is relatively simple to generate an
XML-based IRML rule by parsing a restricted clickable-web form that
allows users to define their preferences.

I guess most of these concerns boil down to my apprehensions regarding
the amount of expertise in the market with XML-parsers as opposed to
BNF parsers-generators. Should ease of development be a criterion ?

Also, would it be possible to mix the features in IRML and P to
develop a mechanism by which structure could be defined by the
XML-based IRML while P syntax is used for expressions, something like:

       <property name="Content-Type" context="res-msg"
                                                   matches="text/html">
         <!-- Is the user's preferred language supported? -->
         <property name="Accept-Languages" context="req-msg"
                                             matches="^de|^fr|^it|^es">
    		<p_expression>
			_DIALUP := 288000;
			client := Http.request.property("User-Agent");
			if ( client == "WAP Browser" or client.bandwidth() < _DIALUP )
			{
				_irml(
			           <execute>
			             <service name="Text Compression">
			               <uri>opes://compressme.com/textcompress</uri>
             			 </service>
           			     </execute>
				);
			}
		</p_expression>
           <!-- Invoke translation service Babelfish -->
           <execute>
             <service name="BabelFish Translation">
               <uri>opes://altavista.com/babelfish</uri>
             </service>
           </execute>
		</property>
         </property>
       </property>

I hope I haven't confused people here. But, C/C++ programmers would
note that this is similar to how ASM code can be placed inline in a
C/C++ program. As you can note, we could allow P language script to
include IRML and vice versa. Would this be a technical noghtmare to
develop ? Any comments on this approach ?

Regards,
Anwar

---------------------------------------
Anwar M. Haneef
Senior Research Engineer
Mobile Platforms and Services Lab
Motorola Labs, Schaumburg, IL 60196

Phone: (847)-576-4939 (o)
Mobile:(847)-514-5192 (m) Pvt.ID: 934
http://www-unix.ecs.umass.edu/~ahaneef
----------------------------------------

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 11 Sep 2003 09:58:10 -0600 (MDT)

On Wed, 10 Sep 2003, Anwar M. Haneef wrote:

> I haven't been an active participant on this list, but have worked
> on OPES for a while (2 years) from an academic standpoint. I agree
> with Andre regarding the compactness of the rule expression
> language. The reason for this is because I don't see the need for
> these rules to be interepreted on the fly.

For the record: even if we decide that compactness is not important
for OPES applications, it is not a negative characteristic either.

> delivery based on QoS and device characteristics.

Could you please post an example or two where IRML lacked expression
power you needed?

> allows users to define their preferences.

I assert that is it equally easy to generate IRML and P rules from Web
forms. Given a form that both languages can support, the code to
generate P or IRML statements would be virtually identical. With P,
the generator MAY perform additional optimizations and/or use
additional form entries, but that is a different story.

> I guess most of these concerns boil down to my apprehensions
> regarding the amount of expertise in the market with XML-parsers as
> opposed to BNF parsers-generators. Should ease of development be a
> criterion ?

I am not sure whether you are saying that there is more expertise with
XML parser generators. If you are, I strongly disagree. Parser
generators existed well before XML and are very well known. In fact,
most XML parsers are written using the knowledge gained from the good
old parsing theory.

> XML-based IRML while P syntax is used for expressions,

What would be the benefit of using XML then?

Alex.