- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Tue, 20 Mar 2001 10:23:31 +0100
- To: "Williams Stuart" <skw@hplb.hpl.hp.com>
- CC: "'Mark Jones'" <jones@research.att.com>, frystyk@microsoft.com, "xml-dist-app@w3.org" <xml-dist-app@w3.org>
"Williams, Stuart" wrote: > [...] > > 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. > > That's probably close to what I think. Module and programming Class seem > like a good analogy, however, I would find an analogy between 'handler' and > an 'object instance' (rather than method) more in line with my thoughts. The analogy is probably more between Module and Abtract Data Type, since I guess a Class also normally includes real code that implements the Class' behaviour. > > 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. > > I think the question you have is how do we denote a 'target' and what sort > of 'thing' is 'targetted'? In the SOAP world, I think 'targets' are denoted > by the URI value of an 'actor' attribute on a header element. I don't think > SOAP really discusses what sort of thing is referenced by the 'actor' > attribute. > > XMLP gives us a chance to revisit (tighten up/clarify) some of this. For > XMLP I think that the sort of thing that is 'targeted' is/will be a > 'handler'. At present I don't know how targets will be denoted - although I > would expect some form of URI reference and I would also expect that > reference to be orthogonal to any URI's that might be used to denote > behavioural rules in the abstract and/or syntactic rules (schema/namespaces > etc.) that a given 'handler' realises. > [...] I have been thinking along similar lines. Jean-Jacques.
Received on Tuesday, 20 March 2001 04:24:13 UTC