Re: dateTime.iso8601 format

>Sorry to drag this out one more message, but if I'm expecting, say, a
>boolean data type for some argument and instead I see a string is a
>fault the correct response?
>
>A fault is pretty limited -- so if a request comes in where I'm
>expecting ten arguments and each one is of the incorrect data type
>should I return a big long message in the fault string about every
>error?

I think it depends on how you expect the client to use the
information.  If the client is just going to present that fault string
to a person for interpretation, then I believe a fault with a big long
message as a fault string is the right way to go.

Though it's hard for me to see how this might apply in the case that
the client sent the wrong type of parameters, sometimes the client
wants to exercise some intelligence about the particular kind of
failure.  In that case, I believe you should call it a success
(because the server successfully figured out why it can't do what was
asked) and return the error information in some structured way as the
RPC result.  I wouldn't do this if the client _doesn't_ have a
pressing need to interpret the information programmatically, because
it's too big a burden on the client program to consider multiple kinds
kinds of successes.

-- 
Bryan Henderson                                   San Jose, California

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/xml-rpc/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/