- From: <noah_mendelsohn@us.ibm.com>
- Date: Thu, 31 Jan 2002 22:37:25 -0500
- To: skw@hplb.hpl.hp.com
- Cc: "'Jacek Kopecky'" <jacek@systinet.com>, xml-dist-app@w3.org, xml-dist-app-request@w3.org
I generally agree with Stuart's sentiments in this thread. Regarding node names vs. role names : first of all, I think we've been clear that role names can be chosen to identify a specific node, or to identify some more abstract purpose (next, cachemanagers, etc.) I think Jean Jacques is right that 4.4.3 needs some cleanup, but I don't think the notion of role name is broken, and I don't think we should be in the business of prescribing how many URI's might be used to identify a node (I believe the web architecture is clear that the same resource can easily have multiple URIs, none of which is necessarily preferred over others.) So, I think none of this is broken in the current spec, except for the need to clean up 4.4.3. Jean Jacques suggests: >> I would be tempted to say that the faultactor >> attribute really ought to identify not just the >> node that faulted (coarse-grained), but the exact >> role in which that node operated (fine-grained). I respectfully disagree with the notion that a node is acting in a single role when doing any particular activity. It is certainly the case that it acts in a non-empty set of roles, and that each header identifies exactly one such role as an actor. On the other hand, it's easy to imagine situations in which processing is triggered by a combination of headers. It may be the combination itself that causes a problem, or it may be that processing triggered by the combination causes a fault. Let's imagine an envelope with a header addressed to actor "TransactionManager" that says "run as transaction" and contains another header targeted to "next" that does some processing. During that processing, an error occurs that results from some interaction between the transaction header and the processing for the header that is labeled "next". I think its very reasonable to ask the node to identify itself with a URI, and I don't think we should say anything about what that URI is. If the node chooses a URI that matches a role, so be it. If it chooses a role that matches one used by the transport bindings, fine too, or it can use anything else. Specifications for applications of or deployments of SOAP might well mandate conventions for the nature of such URI's, but I don't think we should. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Thursday, 31 January 2002 22:52:16 UTC