+1 or a structured address field as it's consistent w/ other addresses in
the spec.

-Lane

On Wed, Jun 24, 2009 at 7:33 AM, Joseph Smarr <jsm...@gmail.com> wrote:

> Looks great! :) One question on location for organization--are you changing
> that to just a simple string value (like in PoCo) or keeping it as a complex
> Address type (as it was when called address)? I'd of course vote for the
> former since it's aligned with PoCo, but just wanted to confirm.
>
> Thanks, js
>
> On Wed, Jun 24, 2009 at 2:24 AM, Jacky <jacky.chao.w...@gmail.com> wrote:
>
>> Hi Everyone,
>>
>> Thanks for all the great inputs!!! =)
>>
>> According to the feedback, the final decision has been put into the
>> "final" column of http://bit.ly/PocoAlignment.
>>
>> Especially, the decisions on the issues stated before are:
>>
>> - Person.age: add to spec description
>> - Person.profileUrl: add to spec description
>> - Person.thumbnailUrl: add to both spec description and XML
>> - Name.additionName / middleName: change to "middle name" to both spec
>> description, PHP and Java Shindig
>> - Organization.address / location: change to "location" to both XML,
>> PHP and Java Shindig
>> - Organization.field / salary / subField / webpage: keep in
>> OpenSocial, add to spec description
>>
>> Please raise your hands if there's any concern remains --- we're about
>> to work on the detailed alignment job such like spec change/code
>> change soon. :)
>>
>> Thanks,
>> Jacky
>>
>> On Jun 24, 3:05 am, Joseph Smarr <jsm...@gmail.com> wrote:
>> > Right, I think the spirit of whatever we do should be a) make it work
>> like
>> > JSON when possible, b) make it compatible for XML consumers, and c) make
>> it
>> > minimally painful for XML consumers that just want/expect POX.
>> >
>> > Thanks, js
>> >
>> > On Tue, Jun 23, 2009 at 10:25 AM, Scott Seely <sse...@myspace-inc.com
>> >wrote:
>> >
>> > >  That was a solution. Again—I just didn’t see this logged anywhere. I
>> will
>> > > happily go with the xsi:type solution.
>> >
>> > > I’m also concerned that the OpenSocial use of XMLNS on the
>> serialization
>> > > will impair the ability to handle XML from PoCo. The reason for an
>> XMLNS is
>> > > to handle versioning on XML docs. This means we should probably have a
>> > > schema but put all the names into the global namespace. This is not
>> great
>> > > for XML, but enhances compatibility. I’m not willing to fight for
>> XMLNS
>> > > because we also support JSON which doesn’t have a versioning story
>> like
>> > > XMLNS. Any versioning solution we come up with for JSON should also
>> work for
>> > > XML.
>> >
>> > > *From:* portableconta...@googlegroups.com [mailto:
>> > > portableconta...@googlegroups.com] *On Behalf Of *Joseph Smarr
>> > > *Sent:* Monday, June 22, 2009 6:07 PM
>> > > *To:* portableconta...@googlegroups.com
>> > > *Cc:* opensocial-and-gadgets-s...@googlegroups.com;
>> > > portableconta...@groups.google.com
>> >
>> > > *Subject:* Re: [opensocial-and-gadgets-spec] Re: Poco alignment: some
>> > > minor mistakes need to be changed on the 0.9 RESTful spec?
>> >
>> > > Scott-are you talking about the XSD issue of how to represent <entry>
>> > > values for people vs activities, etc.? If so, I thought the resolution
>> was
>> > > to get rid of the <person> element and just use <entry> and then also
>> add
>> > > the xsi:type thing if that helps validation, which was deferred to you
>> and
>> > > other XML experts to say if it's worth it. I agree that issue should
>> go in
>> > > the spreadsheet! :)
>> >
>> > > Thanks, js
>> >
>> > > On Mon, Jun 22, 2009 at 2:11 PM, Scott Seely <sse...@myspace-inc.com>
>> > > wrote:
>> >
>> > > I’m missing a statement on how we are proposing to handle entries of
>> type
>> > > Activity, AppData, etc.
>> >
>> > > We need to understand how we handle Activity living at the same place
>> as
>> > > Person—did I miss that in the discussion so far?
>> >
>> > > *From:* portableconta...@googlegroups.com [mailto:
>> > > portableconta...@googlegroups.com] *On Behalf Of *Kevin Marks
>> > > *Sent:* Wednesday, June 17, 2009 8:38 AM
>> > > *To:* opensocial-and-gadgets-s...@googlegroups.com
>> > > *Cc:* portableconta...@groups.google.com
>> > > *Subject:* Re: [opensocial-and-gadgets-spec] Re: Poco alignment: some
>> > > minor mistakes need to be changed on the 0.9 RESTful spec?
>> >
>>  > > On Wed, Jun 17, 2009 at 8:35 AM, Joseph Smarr <jsm...@gmail.com>
>> wrote:
>> >
>> > > For profileUrl and thumbnailUrl, yes they're technically redundant,
>> > > but they're very convenient (and commonly used) by OpenSocial gadget
>> > > developers, so when we did the initial alignment, we agreed to leave
>> > > them in OS as "convenience fields" but under the stipulation that the
>> > > data ALSO has to show up in the official location (e.g. profileUrl
>> > > should also be in the list of urls with type=profile). I think that's
>> > > a smart compromise, so we should leave it as is.
>> >
>> > > As for the remaining issues (middleName vs additionalName and the
>> > > extra organization fields in OS), my vote (not surprisingly) is to
>> > > standardize on what PoCo uses (since we already went thru a lengthy
>> > > debate process to agree on those field names), but in the case where
>> > > OS wants to keep some additional fields (like field/subField for org)
>> > > that's also fine by me since it still keeps PoCo a strict subset of
>> > > OS.
>> >
>> > > Can anyone else weigh in on these remaining issues? In particular, how
>> > > painful would it be to change additionalName to middleName in OS?
>> >
>> > > If we are going to do this, can we add mappings from vcard to the
>> spec(s)
>> > > so that people can tell which field goes where (I know you've done
>> this in
>> > > practice, Joe)
>> >
>> > > Thanks, js
>> >
>> > > On Jun 16, 11:51 pm, Jacky <jacky.chao.w...@gmail.com> wrote:
>> > > > It seems like the field Person.url covers this:
>> > > > person....@type=profile, person....@type=thumbnail, etc...
>> >
>> > > > On Jun 17, 2:44 pm, Chris Chabot <chab...@google.com> wrote:
>> >
>> > > > > On Wed, Jun 17, 2009 at 8:34 AM, Jacky <jacky.chao.w...@gmail.com
>> >
>> > > wrote:
>> >
>> > > > > > - Person.profileUrl: shall we remove it everywhere? It might be
>> fine
>> > > > > > to make this decision consistent with the one for thumbnailUrl
>> ---
>> > > > > > suggest remove.
>> >
>> > > > > profileUrl and thumbnailUrl should definitely stay in the
>> OpenSocial
>> > > spec,
>> > > > > combined with the name they are the bases of social apps (can't
>> show a
>> > > list
>> >
>> > > > > of your friends with pictures and clickable links without those)-
>> Hide
>> > > quoted text -
>> >
>> > > > - Show quoted text -
>>
>
>

Reply via email to