RE: [AM] - Modules and Handlers

As I understand, XMLPApplication is the glue which associates one or more
XMLP handlers together to form a specific configuration (maintaining any
ordering between the handlers and so forth) .  XMLP module, on the other
associates the XMLPApplications to the XMLPBlocks that those handlers can
process.  These are naturally logical abstractions and do not indicate a
physical structure.

=======================================
Waqar Sadiq
Vitria Technologies
13727 Noel Road
Tower 2, Suite 600
Dallas, TX 75240
Phone:   (469) 385-3046
Fax:       (972) 739-2465
======================================= 

-----Original Message-----
From: Mark Jones [mailto:jones@research.att.com]
Sent: Thursday, April 12, 2001 1:19 PM
To: jones@research.att.com; rhinewu@hotmail.com; xml-dist-app@w3.org
Subject: Re: [AM] - Modules and Handlers


	> From: "Rhine Wu" <rhinewu@hotmail.com>
	> To: "Mark Jones" <jones@research.att.com>, <xml-dist-app@w3.org>
	> Subject: Re: [AM] - Modules and Handlers
	> Date: Fri, 13 Apr 2001 01:48:12 +0800

	> You mean " XMLP Application = XMLP Processor " and " XMLP Handlers
= XMLP
	> Modules " ??
	> It sounds strange.

If by "=" you mean "stands in 1-1 correspondence with", then this is
about right.  There has been some discussion about whether it was
necessary to have a separate notion of "the behavioral abstraction of
X" in addition to "X" (for example, a handler being the behavioral
abstraction of a module).  For the moment, we have the distinctions.

	> I think XMLP Processor handles all the process rule (
XMLP_UnitData ) and
	> communicate with
	> XMLP Application . And XMLP Application dispatchs XMLP blocks to
XMLP
	> Handlers .

This is pretty close.  It is also possible to dispatch a handler which
processes no blocks.

Relating again to the first point, by couching things in terms of
behavioral abstractions, it gives implementational flexibility.  There
may be radically different API's for invoking the module behavior.  It
could even be hardwired into the processor/application software; in
this case there wouldn't necessarily be an implementation artifact
that directly corresponded to a "dispatched handler".

--mark

	> Please correct my statement. Thanks.

	> Best Regards,
	> Rhine


	> > As it stands, I think XMLP Application refers to the behavioral
	> > abstraction of the XMLP Processor which carries out the
dispatching of
	> > XMLP Handlers, the behavioral abstractions of XMLP Modules.
	> >
	> > (Sorry to be so abstract, but we've made an effort to distance
	> > ourselves from any commitment to more concrete
realizations/models of
	> > these abstractions.)
	> >
	> > --mark
	> >

Received on Thursday, 12 April 2001 14:50:54 UTC