On Fri, Dec 5, 2008 at 1:55 PM, Henning P. Schmiedehausen < [EMAIL PROTECTED]> wrote:
> Thanks Adam for answering my question on the spec list. So here is my > question: The various model objects say in their header: > > * Base interface for all address objects > * see > http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.Address.Field.html > . > > and > > * Base interface for all name objects. > * see > http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.Name.Field.html > > > So do they track the Javascript side of the spec? Because if they do, > then there should be a translator somewhere between the REST/RPC code > (which, according to Adam) uses a different field name. But, again > according to Adam, it is the other way around. The Javascript field > name gets translated to the REST/RPC names. IAW: It seems that > FORMATTED would be correct, not UNSTRUCTURED. At least for 0.8.1. > > As SHINDIG-764 was applied, I guess, we are really shooting for 0.8, > not 0.8.1 with the first release. No, it's 0.8.1. The JS did not change from 0.8 to 0.8.1 (because of the lack of a versioning strategy for JS, I'm told), the wire formats did (to align with Portable Contacts).happened Why am I nagging on this: Our implementation has a pretty anemic > profile model ATM and UNSTRUCTURED is one of the fiew fields that we > support. Changing its name means that our backend people need to > modify their code. The proper name - for the bean and for the JSON - is "formatted". SVN revision 723617 needs to be rolled back. SHINDIG-764 should have been closed as not-a-bug. -- Adam > > Ciao > Henning > > > -- > Henning P. Schmiedehausen - Palo Alto, California, U.S.A. > [EMAIL PROTECTED] "We're Germans and we use Unix. > [EMAIL PROTECTED] That's a combination of two demographic groups > known to have no sense of humour whatsoever." > -- Hanno Mueller, de.comp.os.unix.programming >
