So you are saying according to the spec Account for example should be a subclass of a PluralField object which has the properties defined within the spec [1], right?
[1] http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Data.xml#Plural-Field On Tue, Oct 16, 2012 at 4:06 AM, Jan Willem Janssen < janwillem.jans...@luminis.eu> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/13/12 12:30 AM, Henry Saputra wrote: > > As for your question, I think I am kind of loss on what your > > concerns are? > > > > Could you give a bit more example of what conflict or confusion > > about matching the fields for the Person data type with the spec? > > For example, taken the following fields: > > - - "accounts": the spec defines this field as PluralField<Account>. > Shindig implements this as List<Account>, with no possibility to > specify the primary account; > - - "addresses": also a PluralField<Address>, which is implemented in > Shindig as List<Address>, while the Address object has a field > primary; > - - "emails": PluralField<Email>, implemented as a List<ListField> in > Shindig. > > So it appears there are three ways of defining a PluralField in > Shindig (actually two: the first item is a bug IMO). Which one should > be used for adding new PluralFields? > > In addition: there are several fields in Person implemented as > enumeration of fixed values, while the spec doesn't mention anything > on these value constraints (e.g. "drinker"). Shouldn't these fields be > made less restricted? > > - -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > /My world is:/ > > Luminis Technologies B.V. > IJsselburcht 3 > 6825 BS Arnhem > +31 88 586 46 30 > > http://www.luminis-technologies.com > http://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8169.78.566.B.01 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJQfRWKAAoJEKF/mP2eHDc4VZgP/iee9ZzbTrHT8dBCgrU8IRb7 > 0ECpdcW7/7RRieQLOp5whA8SLrmwumnht0l41xvCzgfvrBbvgypcIXnqOnV9Vvho > pKnOvKXskIvgUZnzCWUoGDc71wRIhCxHzkvLT7oNV+nvgIVvyrco/JHNtasTUdp2 > jdKcGavdsUmNHECY18mevTgK9ciff2DEHakxhKu8yqVKLXRPtDx9Drd59fLzgsT5 > Dpv7JrK/+M2iM96VX0lsKDwZl5ThP6aZYCBucuJ0Pxn6H1BwQqV+Do71lnl2pkxX > sw5hAF279iNLIZ1G6QcsgBhKvpgW4S0HOJvjqGa82YcXli1CWRYRFd6UlZbd6gPE > nRt3XrZxpg+6+wocePuwLIUCFPzQWYcRxECCWaJXyVOT96NWQ5gDwV5IPbCFwWal > UxvkQGxOQAkvaxrihjyBiaidO3yV5etPzXjH+q7VkquA8t/uOXJYap4pJfAqJkTs > sE/SEQY8QffGP17NPcuj8WKj1iPuNp67gLtPK81tSam5KOHbfxULg9Y9I2PAKNsO > SL6sG7ar38LKXrcyFXwp12k18txA9KXAbjdYJq0BKDgETSuaSc23gGVpNzuslR4e > jucJ6jQSENB/cVZSVpAHHCUFh/jJAYp8phuVjDVdLHccdfht/pN2eBg10PUbzW+U > tWDC4isjvH2u6cMy55xd > =X7yk > -----END PGP SIGNATURE----- > >
