Re: Issue #170 proposal - referencing to missing data

I am using weak reference in its generic sense:  a reference that can 
appear to be present, but is not considered to be in error if it cannot in 
fact be successfully used to retrieve a target.  I think that's the same 
definition you are using.   The reason I think we have a relationship 
between weak references and optional arguments is that in SOAP, the 
arguments to an RPC are modeled as a struct.  If we don't have some notion 
of weak references, then there is a decoding failure in even attempting to 
build the struct, I.e. before we can worry about which argument is which. 
That's the reason I used function arguments as an example of weak 
reference.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







Jacek Kopecky <jacek@systinet.com>
Sent by: xml-dist-app-request@w3.org
12/04/2001 11:11 AM

 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     <xml-dist-app@w3.org>, (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        Re: Issue #170 proposal - referencing to missing data


 Noah,
 of course the fault would be generated when a processor actually
encounters a reference it cannot resolve. I don't want to mandate
that all data be deserialized even when unnecessary.
 Anyway, I'm very nervous about you tying the term weak reference
with an optionally handled argument. Weak references, as I
understand them (according to Java), are references to data that
can disappear and the reference can still be handled graciously.
Optionaly handled arguments, as in LISP's (if a b c) form,
require some implementation support but don't require weak
references, on the other hand weak references don't always (nor
usually IMO) mean optionally handled arguments.
 I think that we don't need to put weak references into our data
model as they can be handled by the application equally well and
the slight optimization of weak references being inside our data
model and encoding is outweighed by the disadvantage of the
additional complexity, while weak references are used only in
very few special applications.
 Actually, the same argument could be used on partially
transmitted arrays. 8-)
 BTW, I think the current encoding does not forbid lazy
deserialization, IMHO, which can be used for implementing
optionally handled parameters.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 4 Dec 2001 noah_mendelsohn@us.ibm.com wrote:

 > 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 Thursday, 6 December 2001 10:36:14 UTC