RE: Finalised Glossary Definitions

Comments at end.

	From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
	To: "'Mark Jones'" <jones@research.att.com>, moreau@crf.canon.fr
	Cc: frystyk@microsoft.com, xml-dist-app@w3.org
	Subject: RE: Finalised Glossary Definitions
	Date: Tue, 20 Mar 2001 14:33:11 -0000

	Hi Mark,

	> -----Original Message-----
	> From: Mark Jones [mailto:jones@research.att.com]
	> Sent: 20 March 2001 14:17
	> To: jones@research.att.com; moreau@crf.canon.fr
	> Cc: frystyk@microsoft.com; skw@hplb.hpl.hp.com; xml-dist-app@w3.org
	> Subject: Re: Finalised Glossary Definitions
	> 
	> 
	> 	From moreau@crf.canon.fr Tue Mar 20 03:53 EST 2001
	> 	Delivered-To: jones@research.att.com
	> 	X-Authentication-Warning: lancelot.crf.canon.fr: smap 
	> set sender to <moreau@crf.canon.fr> using -f
	> 	Date: Tue, 20 Mar 2001 09:52:59 +0100
	> 	From: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
	> 	X-Accept-Language: en,fr
	> 	MIME-Version: 1.0
	> 	To: Mark Jones <jones@research.att.com>
	> 	Cc: frystyk@microsoft.com, skw@hplb.hpl.hp.com,
	> 	        "xml-dist-app@w3.org" <xml-dist-app@w3.org>
	> 	Subject: Re: Finalised Glossary Definitions
	> 	Content-Transfer-Encoding: 7bit
	> 
	> 	Mark Jones wrote:
	> 
	> 	> My problem, particularly for talking about the processing model,
	is
	> 	> that I need terms for
	> 	>
	> 	> (1) "the thing that knows enough about the semantics of a block
	(given
	> 	>     its tag) to map it to a thing that implements a very specific
	> 	>     piece of behavior"
	> 	>
	> 	> (2) "the thing that implements a very specific piece of behavior
	given
	> 	>     a block"
	> 	>
	> 	> I think of (1) as a module, something like a class in programming
	> 	> language terms.  I think of (2) as a handler, something like a
	method
	> 	> name.
	> 	>
	> 	> If we make (1) the whole processor and (2) a handler, then it
	raises
	> 	> the question about how the processor came to know enough about the
	> 	> semantics of things (blocks, behavior, etc.) to make such a
	> 	> determination. [...]
	> 
	> 	Mark, I am wondering why (1) would have to know "about the semantics

	>	of a block" to do any sort of dispatching. After all, a Web browser
	does 
	> 	not know anything about the semantics of a particular MIME document,
	and is 
	> 	nevertheless capable of firing up the appropriate plugin. Why would 
	>	block dispatching be different?
	> 
	> 	Jean-Jacques.
	> 
	> 
	> Some blocks will indeed represent declarative info Other blocks,
	> including RPC blocks, are best seen as encoding some kind of intended
	> semantics (order a book from Amazon, etc.).  The processor determines
	> a handler based on the block tag.  My point was just that a processor,
	> right out of the box, doesn't know anything about such mappings.  It
	> is only when a specific module is added to the processor, that it gets
	> parameterized with this mapping.  It is the module that inherently
	> knows about the mapping.
	> 
	> --mark

	I got so close to saying 'Yes' and something just slipped from my fingers
	with the last sentence. My question is are you using 'handler' and 'module'
	synonymously? If you are then I understand the point you are making, and if
	not then I would find it helpful to understand how you would articulate the
	difference between module and handler (again).

	Thanks,

	Stuart

Here's the distinction I am drawing.  Fundamentally, a particular
handler is code.  It has inputs (blocks) and outputs (blocks
to add to the message or return from the message, side effects
on the world).  People seem to roughly agree on that.

A handler is passed some block(s), may cause some side-effects in the
world, may contribute some new blocks to the message, etc.
A handle signature is something like:  handler (in blocks, ...).

From the handler definition, you can't infer that handler1 should get
blocks of type A and handler2 should get blocks of type B.  You can't
infer that handler1 and handler2 are related, or that handler1 should
be run before handler2.  Where does this knowledge live?  I think of a
"module" as being the locus of the knowledge that ties together
related syntactic features (blocks) and behavior (handlers).

So my notion of module encompasses:
(1) a set of related handlers
(2) a set of related block definitions
(3) an understanding of the relationships among the items in (1) and (2)

When a module is added to a processor, it brings with it the behavior
(handlers), the mapping between blocks and handlers, execution constraints,
etc.  It is a modeling and implementation issue as to whether
 (a) this knowledge is simply absorbed into the processor's own global
     structures and the notion of a module practically ceases to exist
     at run-time, or
 (b) the processor algorithms actively incorporate a module API
     which keeps the knowledge encapsulated

(a) seems to be the SOAP approach.

By the way, it seems to me that a module must encompass both the
knowledge about how to CONSTRUCT an appropriate message (or parts
therein) as well as how to INTERPRET those parts on the receiver side.
We've tended to ignore the constructive side, but there must be some
API for the sender which takes a relatively high-level
characterization of the required behavior and manufactures the
appropriate blocks.  This API should be modular so that independent
blocks can be inserted and targeted independently, while still
permitting any necessary dependencies (e.g., ordering).

I think it is clear that the concepts of module and handler are
distinct and both useful.  Particular conventions tend to cloud up the
distinction in simple cases.  For example, if there is a convention
that fixes the relationship between an element tag and the name of a
handler, then the mapping between blocks and handlers becomes trivial
and can be hardwired into the processor.  If, furthermore, there is
only one handler per module, then it makes "module" and "handler" seem
interchangeable since there is a 1-1 relationship and there aren't any
constraints among handlers to worry about.

--mark

Received on Tuesday, 20 March 2001 11:04:38 UTC