- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 4 Dec 2001 10:18:33 -0500
- To: Jacek Kopecky <jacek@systinet.com>
- Cc: xml-dist-app@w3.org
Whenever we mandate a fault, we must be very careful about ordering. I would be reluctant to do anything that forced processsing, particularly of a large message, to proceed in any particular order. Consider the case where there are several problems with a message, some related to encoding and some not. If we mandate the generartion of an encoding fault, then we might be forcing processors to do more decoding than the application needed to discover other problems. Furthermore, there's a general issue of weak references. What if you're doing RPC and by looking at argument #1 you decide that you don't even need to mess with argument #3. Should we still mandate that you check for the fault in a bad reference out of #3? I think not. Therefore I prefer Henrik's suggestion: offer a standard fault that MAY be used, and indicate that failure to resolve a reference indicates that there is no value available for the node in the graph (a new state we haven't had before) and that processors MAY generate the standard fault when this situation arises. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Tuesday, 4 December 2001 10:30:47 UTC