Attribute Exchange pre-draft 5

[Dick Hardt]

On 3-Apr-07, at 3:32 AM, Josh Hoyt wrote:
> If I understand correctly, the response to a request for an attribute
> with "count.x=1" is different from the response for a request with no
> count specified, even though the meaning is the same.
>
> (namespacing left off for clarity)
>
> Request:
>
>  .type.a=http://example.com/a
>  .count.a=1
>  .type.b=http://example.com/b
>
> Response:
>
>  .type.a=http://example.com/a
>  .count.a=1
>  .value.a.1=avalue
>  .type.b=http://example.com/b
>  .value.b=bvalue
>
> Even though the request for a and b have equivalent meaning (send zero
> or one values for this attribute) the response MUST encode them in
> different ways. I think this is ugly, because the detail of the way
> that the attribute was requested has to be preserved in the code, to
> ensure that the response can be encoded correctly. (it's not
> sufficient to just default the count to one if it's not specified)

>
> Is there a reason that it's specified this way? I'd prefer if there
> was only one way to do it.

Good point. Either .count. has to be more then 1 in a request so that  
there is only one way to do it,
or the response could be in either form where .count.=1 to be  
consistent with the request being able to be in either form.

>
> Also, can the count be zero in the response? it seems like that's OK,
> and if it is, it'd address my concern about overloading zero-length
> strings to mean "no value."

Another good point. I agree it should be able to be zero.

-- Dick