and what i replyed to this response..
Same principle applies.
All are stored in sets.
homeStreet,homeCity,homePostalCode,homeCountry make up the first set.
homeStreet2,homeCity2,homePostalCode2,homeCountry2 make up the second set.
Same goes for work... and other...
You just need to adjust your isset checks to look for the existence of any one of the 4 pieces of information for any given address set
NOTE: The zimbra web UI does a bad job of SAVING these if you do as you said - just enter random single pieces of information in for each address.
Actually we can not say it is a bug of the web ui.. that is the only problem i am talking about.. user can enter anything of any type inside address.like you tried to enter 5 addresses of same type HOME. now what happens is when we try to fetch that contact from SOAP request,the resulting response has muddled attributes. this is the default behavior and we can not say it is a bug.so that is why i am suggesting to have some arragement of attribute data. now imagine a worst case having 5 addresses and each having only City field. now when we will fetch that contact, the response will contain something like this.
Now this is the usual response we get through SOAP request. so once we get this data,arrays of A tag is prepared.now think how you will parse addresses. because you dont know the arrangement ! also to parse simple data like firstName or lastName, we must travers entire array. and according to me this is not efficient. so i suggest they must have some proper ordering. so it is a severe problem of arrangement and not a bug.