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 -
