+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 - >> > >