Attribute Exchange pre-draft 5

[Josh Hoyt]

On 3/26/07, Johnny Bufu <johnny at sxip.com> wrote:
> Since draft_4 [1] we've done some implementation and testing (as well
> as listened to community's suggestions on related issues), and have
> incorporated some changes into a pre-draft-5. Before publishing it I
> would like to see your comments about them or about other features /
> changes that would be useful in AX.

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.

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."

Josh