- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Thu, 31 Jan 2002 14:29:40 -0800
- To: "Jacek Kopecky" <jacek@systinet.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>
- Cc: <xml-dist-app@w3.org>
I agree with Jacek that it seems problematic to distinguish between node and actor. I think we have to be careful with our use of the term "role" and "actor" as I don't think the analogy with the silver screen holds. There, the term "role" implies that there is an actor and that the actor has a name that is different from the role. That is, we can have "Sean Connery" (the actor) acting as "James Bond" (the role) and normally we distinguish between referring to Sean or to James as they are different entities. Furthermore, it is only under certain conditions that "Sean Connery" and "James Bond" are the same, "James Bond" could also refer to "Roger Moore" and so on. In the current SOAP model, we only have one identifier which is the value of the actor attribute. Any form of "equality" between references has to be determined out of band. For example, our "next" URI defines out of band (in prose in our spec) that it is equal to any identifier identifying the receiving SOAP Node when it is present in a SOAP message. The equality could also be stated declaratively as a set of statements asserting that two identifiers are the same under certain conditions, or it could be determined implicitly by some resolver mechanism. Note that we say nothing about *how* one resolves the actor name as resolution is a matter of trust. That is, I can have names that are resolved to identify a specific SOAP node using some out of band mechanism or names that are resolved using DNS. The "next" URI is an example of the former. For better or for worse, I think the current description in SOAP 1.2, part 1 section 2 is adequate and consistent with the general Web architecture of URI references. I therefore suggest that we leave it as is. Henrik > I think that even though more complicated, modeling it as an >extension would be much cleaner because of avoiding all that >node stuff in the core. Additionally, adding faultNode would >IMHO _not_ be consistent with faultActor because actor is a >known and used and well defined term, whereas node was so far >only an abstract term. For these reasons I would initially >oppose to the WG discussing this addition. But then, the >discussion has already started as >this dialog. 8-)
Received on Thursday, 31 January 2002 17:30:22 UTC