Re: Finalised Glossary Definitions

	From moreau@crf.canon.fr Tue Mar 20 10:21 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 16:21:26 +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
	Subject: Re: Finalised Glossary Definitions
	Content-Transfer-Encoding: 7bit

	Mark Jones wrote:

	>         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.).

	In my view of the world, the RPC Handler would deal with the RPC-related semantics  ("oh yes, this is an RPC
	block, let's call the appropriate function"), whilst the function itself would take care of the book-related
	semantics ("let's order this book from Amazon"). But I guess I see choosing the RPC Handler in the first place
	as purely syntactic (i.e. string matching on actorURI or blockTag).

But I could as easily encode the request to order the book as ordinary
XML markup and not use the RPC conventions.  The RPC conventions are
exceptional in terms of making the syntax/semantics mapping so transparent.

Here's an example that illustrates both kinds of blocks that I had in
mind above.  For simplicity, just assume that all processing takes
place at the same processor and that these are blocks in the message.

   <v:vcard xmlns:v="vcard-ns-URI" id="some-id"> ... vcard data ... </v:vcard>
   <x:action1 xmlns:x="x-ns-URI"> ... action1 data ... <vcard href="some-id"> ... </x:action1>
   <x:action2 xmlns:x="x-ns-URI"> ... action2 data ... <vcard href="some-id"> ... </x:action2>
   <y:action3 xmlns:y="y-ns-URI"> ... action3 data ... <vcard href="some-id"> ... </y:action3>

Now, there isn't any application activity really to be directly
associated with the first block.  It is just declarative data to be
referenced by the other blocks, which will be processed by some
handlers (H1, H2, H3).  These handlers could be different or the same
and don't necessarily bear any systematic syntactic relationship to
the element tags.  The question is: where does the knowledge come from
to map x:action1 to H1, x:action2 to H2, y:action3 to H3 and v:vcard
to none?

I've been using the term module to refer to the thing that
encapsulates this knowledge that relates block syntax and behavior.
The processor is obviously the component that utilizes the knowledge
since it controls evaluation, but processors get the knowledge from
the modules that are added to configure them.

Every handler has to know how to interpret the blocks that it
processes, whether the blocks use RPC conventions or not.  In this
sense, there isn't really any need to explicitly mark a block as RPC.
As long as the sender and receiver agree on the interpretation of the
block, they can use any convention that they like.  (Although a standard
convention for how to do RPC is certainly useful.)

	>  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.

	We will probably need to settle on a shared understanding of what a module is... sometime soon!  :)

	Jean-Jacques.

I agree.

--mark

Received on Tuesday, 20 March 2001 11:57:12 UTC