Re: Finalised Glossary Definitions

Mark Jones wrote:

> [...]
> 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 would say: from the actor attribute -or some other attribute that carries the appropriate information. Actually, the
difference between our two approaches may be that you delegate/delay the actual binding to the processor/module, whereas I
do it upfront in the client, and the processor just follows a URI. In a sense, this is like dynamic binding vs. static
binding.

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

I don't think this is the definition of module we have in the glossary. I think you are introducing a new concept, that
begs a new name -unless "Processor" is the thing. Comments anyone?

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

Jean-Jacques.

Received on Wednesday, 21 March 2001 09:29:32 UTC