W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2001

Re: SOAP actor model

From: Mark Jones <jones@research.att.com>
Date: Mon, 19 Mar 2001 19:39:03 -0500 (EST)
Message-Id: <200103200039.TAA23412@glad.research.att.com>
To: jones@research.att.com, mnot@akamai.com
Cc: frystyk@microsoft.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
	Date: Mon, 19 Mar 2001 12:49:21 -0800
	From: Mark Nottingham <mnot@akamai.com>
	To: Mark Jones <jones@research.att.com>
	Cc: frystyk@microsoft.com, skw@hplb.hpl.hp.com, nxml-dist-app@w3.org
	Subject: Re: SOAP actor model

	On Mon, Mar 19, 2001 at 02:42:42PM -0500, Mark Jones wrote:

	> If I correctly understand the threads that have been taking place,
	> another view is that the actor can not only be used to verify that the
	> appropriateness of the processor, but can also designate a specific
	> handler or possibly a module.

	I wonder if it's appropriate to overload the actor with this
	additional functionality. If we need something to narrow down the
	handler which we want, why not use a different attribute?

	Mark Nottingham, Research Scientist
	Akamai Technologies (San Mateo, CA USA)

I spoke to Henrik today, and he thinks it is better to overload the
block tag.  Some blocks would be purely declarative -- this is a vcard,
for example.  Other (actionable) blocks would have more
processing-oriented tags that the processor would bind to a handler.
These tags would either surround a declarative block, or possibly
point to a declarative block, particularly if the block needed to be
processed in multiple ways.

I'd be willing to go this route instead of "overloading the actor",
although I actually don't view it as overloading.  My point was that
the actor would be a designation of the "the kind of processor
that should handle this block" by either having a binding/handler
in the processor's environment or not.  Currently, the actor is somewhat
underutilized -- with only special URI's signifying the next processor
and the last processor.


Mark A. Jones
AT&T Labs
Received on Monday, 19 March 2001 19:39:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC