Loading ...
Sorry, an error occurred while loading the content.
 

RE: [json-rpc] 1.1WD: Null values and missing parameters.

Expand Messages
  • Atif Aziz
    Hi Graham, Let me give you the background to what may seem like conflicting statements but really aren t intended that way. The spec was written with the wire
    Message 1 of 2 , Nov 8, 2006

      Hi Graham,

       

      Let me give you the background to what may seem like conflicting statements but really aren’t intended that way. The spec was written with the wire message in mind first and then goes on to define how each side of the wire may place that message and interpret it. There’s very little in the spec about languages and all the various features that the protocol is trying to support. Not all languages are created equal so some bindings will be more troublesome to implement than others, which is why it’s also better to focus on the message itself. The rationale is easily explained if you imagine a dense procedure.

       

      The Null value MAY be used as the value of any parameter and MUST be taken to mean that the parameter is not being supplied for the call.

       

      So take a procedure called “foo” with 10 parameters named “a” through “j”.  Imagine further that we want to call this procedure with only the 2nd and 7th parameters having a value. In language with named parameters, this may look like this:

       

      foo(b = 12, g = 34)

       

      In a language without named parameters, this may look ugly as:

       

      foo(null, 12, null, null, null, null, 34, null, null, null)

       

      On the client side, what the spec is really permitting is for the protocol implementation to ship the latter as the former. In other words, the second form can be collapsed on the wire so that both appear as…

       

      { "method" : "foo", "params" : { "b" : 12, "g" : 34 } }

       

      The second statement that you found contradictory is what actually helps the server to expand the call back to how it may have been logically supplied…

       

      If the call supplies fewer parameters than expected then the missing parameters SHOULD assume the Null value.

      So the terse message gets expanded back to the following, especially in the second case:

       

      foo(null, 12, null, null, null, null, 34, null, null, null)

       

      If you will, it was written in the interest of producing smaller call expressions where extra noise can be dropped to send just a clean signal.

       

      Now if you’re working in Python, then yes, calling foo like this

       

      foo(b = 12, g = 34)

       

      could, with the function definition giving all parameters a default value of -1, actually mean to say

       

      foo(-1, 12, -1, -1, -1, -1, 34, -1, -1, -1)

       

      But then that only works for developers where the client and server are implemented using languages with similar features. Moreover, I feel it’s generally a bad idea to make an explicit distinction between a missing member in a JSON object and that member being supplied with a value of null. It overloads the processing and mental picture unnecessarily.

       

      - Atif

       

      P.S. I’ve been in crunch mode at work these days and will remain for some time to come. I’ve read your feedback and hope to follow up some time soon. Meanwhile, don’t be disheartened from sending feedback in the future in case you felt nobody was picking up your current concerns. Personally, I’m just in a bit of squeeze.

       


      From: json-rpc@yahoogroups.com [mailto: json-rpc@yahoogroups.com ] On Behalf Of dscplcomau
      Sent: Sunday, October 15, 2006 5:44 AM
      To: json-rpc@yahoogroups.com
      Subject: [json-rpc] 1.1WD: Null values and missing parameters.

       

      I haven't browsed through all the posts on the list about the specification and thus do not
      know if these issues have been covered already or not, but I provide them all the same. I
      actually have a few issues, but I will send them as distinct emails so each can be discussed
      independently.

      In "6.2.3. Null Parameters", it states:

      The Null value MAY be used as the value of any parameter and MUST be taken to mean
      that the parameter is not being supplied for the call.

      and then in "6.6.1. Call Approximation" it states:

      If the call supplies fewer parameters than expected then the missing parameters SHOULD
      assume the Null value.

      The problem is that it isn't totally clear how this relates to any Procedure being called and
      it could have the affect of changing the result of a function or an inability to match a
      Request to a function in the first place.

      The issue is that many languages actually allow a Null value to be passed as a parameter
      to a function with the implementation of the function being allowed to interpret the
      presence of a Null value however it wants.

      Lets consider first where the Request used an Object (as opposed to an Array) for the
      params and it used integer positional values for the labels for each value. If this Procedure
      accepted a set number of parameters and one of the params was supplied as a Null value,
      what does this mean. The specification seems to suggest that it should be interpreted as
      that the Null value parameter was never supplied in the first place. If this is the case, the
      consequences would be that it wouldn't be possible to map the request to the Procedure
      and call it as the number of params would not be the correct number.

      Thus, I would suggest that the interpretation of a Null value is wrong. Any Null value
      should always simply be passed as the value of the parameter of the Procedure. It should
      not mean that the parameter was not supplied.

      Lets consider another example where named parameters are used instead of integral
      positional values. Imagine here that the language being used to implement a Procedure
      supports default parameters. That is, if the parameter isn't supplied, then the Procedure
      will use a default value as specified as part of the prototype or interface of the Procedure.
      Take it that a default parameter exists where the default value is 1. Also take it though
      that if a Null value is supplied that the Procedure interprets that as having some special
      meaning.

      With the way that the specification is written whereby a Null value means that the
      parameters was never supplied in the first place, it becomes impossible to pass the Null
      value to the Procedure and in this case though, because there is a default value for the
      parameter, the calling mechanism would still say it is okay to call the Procedure, but
      instead of using Null as the value, it would fallback to the default of 1. Thus the input to
      the Procedure is not what was desired.

      So, the first bit of the specification states that a Null value means that the parameter
      wasn't supplied, but then looking at the second, it says that if a parameter isn't supplied it
      should take on the Null value. Referencing back to the first statement, does this imply it
      should be treated as the parameter was never supplied, or are you saying now that the
      literal Null value should be passed as the parameter.

      If it is the latter, then the first statement doesn't make sense as it effectively prevents a
      Null value being actually passed as a parameter. If it isn't the latter, then why state it.

      Thus, all very confusing. What I would very much suggest how it should be interpreted is
      that if Null is supplied explicitly as a parameter, that that value should be passed to the
      actual Procedure. If a parameter is missing, then the calling mechanism should determine
      if the implementation of the Procedure specifies a default value for that parameter and if it
      does, it should use that default value. Otherwise, the calling mechanism should deny the
      call because of not all parameters being supplied. In other words, the calling mechanism
      by itself should not assume that a Null value can be substituted for parameter if not
      supplied, as doing so may change the semantics of the input data for the Procedure.

      In other words, it should work like how function calls in a normal language work. The
      specification changes it something else.

      Graham

    Your message has been successfully submitted and would be delivered to recipients shortly.