Draft spec documents for 0.8.1 now staged at opensocial.org

[Arne Roomann-Kurrik]

Updated versions of the spec docs are now staged for review on opensocial.org:

OpenSocial Release Notes

http://www.opensocial.org/Technical-Resources/staging/opensocial-release-notes

OpenSocial Specification -- Implementation Version 0.8.1
http://www.opensocial.org/Technical-Resources/staging/opensocial-specification----implementation-version-081

opensocial-reference
http://www.opensocial.org/Technical-Resources/staging/opensocial-reference

Restful Protocol
http://www.opensocial.org/Technical-Resources/staging/restful-protocol

RPC Protocol

http://www.opensocial.org/Technical-Resources/staging/rpc-protocol

We're looking for consensus without any -1s in order to make these go live.  Please point out any inconsistencies or inaccuracies you see!

Thanks,

~Arne

--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Scott Seely]

It seems that section 11.1 of http://www.opensocial.org/Technical-Resources/staging/restful-protocol adds features not found in http://www.opensocial.org/Technical-Resources/staging/opensocial-reference. I would like to see this group consider dropping any inventions in the REST spec and normalizing/adding to the REST spec field names found in the opensocial-reference spec. Given that our only time pressures are self-imposed, we should not rush in getting 0.8.1 out the door.

 

 

Here is the specific call out:

 

Singular fields:

·         published (new)

·         updated (new)

·         birthday (Should normalize with DATE_OF_BIRTH in the JS. Let’s rename to dateOfBirth)

·         anniversary (new)

·         note (new)

·         preferredUsername (new)

·         utcOffset (should normalize this with TIME_ZONE in the JS to change TIME_ZONE to UTC_OFFSET)

·         connected (should normalize this with NETWORK_PRESENCE in the JS. Let’s rename this one to networkPresence. This way, it’s also not a Boolean, but a broader set of settings like AWAY, CHAT, ONLINE, OFFLINE, etc.)

 

Plural fields:

·         ims (new)

·         photos (new) I think we have a better alternative on the 0.9 horizon. The collection of photos sounds like an Album whose type is restricted to opensocial.MediaItem.Type.Image. I think we could reduce this field to an Album ID and keep the overall API a lot cleaner.

·         Since the feature doesn’t seem to be integrated across the specs and we probably don’t want to hold things up, we should remove this item.

·         relationships (this seems to conflict in name with RELATIONSHIP_STATUS)

·         organizations (JS still has SCHOOLS and JOBS broken out. We should be consistent across models.)

·         accounts (new)

 

Several fields found in a JS Person are not found in the RESTful API:

·         ABOUT_ME

·         AGE

·         BODY_TYPE

·         BOOKS

·         CARS

·         CHILDREN

·         CURRENT_LOCATION

·         DRINKER

·         EMAILS

·         ETHNICITY

·         FASHION

·         FOOD

·         HAPPIEST_WHEN

·         HAS_APP

·         HEROES

·         HUMOR

·         INTERESTS

·         JOB_INTERESTS

·         JOBS

·         LANGUAGES_SPOKEN

·         LIVING_ARRANGEMENT

·         LOOKING_FOR

·         MOVIES

·         MUSIC

·         PETS

·         POLITICAL_VIEWS

·         PROFILE_SONG

·         PROFILE_URL

·         PROFILE_VIDEO

·         QUOTES

·         RELATIONSHIP_STATUS

·         RELIGION

·         ROMANCE

·         SCARED_OF

·         SEXUAL_ORIENTATION

·         SMOKER

·         SPORTS

·         STATUS

·         TURN_OFFS

·         TURN_ONS

·         TV_SHOWS

 

This again needs to be rectified. All these items are in the schema for the XML format, but we don’t have a defined mechanism in the spec to call these out for @supportedFields. Even though they are optional in implementations and implementations can support these, it would be good to normalize the names of these fields between the JS and REST specs.

 

Looking at 11.1.3 (Name)

·         formatted (JS has ‘UNSTRUCTURED’—the two should agree in name)

·         middleName (new) Please note that ‘middle name’ is not common in all cultures and will cause issues.

·         Missing ADDITIONAL_NAME (which is probably a more issue free mechanism to handle the ‘middle name’ issue).

 

11.1.4 (Address)

·         formatted vs. UNSTRUCTURED_ADDRESS in the JS. Let’s normalize by setting JS to FORMATTED

·         Missing: EXTENDED_ADDRESS, LATITUDE, LONGITUDE, PO_BOX, TYPE

·         Other issue: the streetAddress in 11.1.4 claims to subsume many fields that are individually expressed in the opensocial.Address JS. This is inappropriate as the JS has higher quality data. Ex.: with the REST bits, I need to guess what the PO Box is. I don’t do this with the JS.

 

11.1.5 (Organization)

·         department (new)

·         location seems to be the equivalent of address. Let’s just make the REST version be address

·         Missing: FIELD, SALARY, SUB_FIELD

 

11.1.6 (Account)

·         No equivalent in the JS spec. Let’s drop this item until 0.9.

 

 

 

Scott Seely

architect

email  sse...@myspace.com

[Cassie]

The renames and additions to the person object (and sub objects) were specifically made to align the opensocial restful spec with the portable contacts spec. This was proposed and approved by the spec list as part of 0.8.1

I hope we will get the javascript on the same page as the restful spec but we will need to wait for 0.9 to change things. For the moment there is a simple mapping between elements (shindig has an impl in javascript if you would like a reference).

- Cassie

[Scott Seely]

My apologies. I’ll be tracking this and other issues so they don’t fall through the cracks when we are ready to open discussions for v.Next. To keep my list easy to see, I’ll be posting it to http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Issues. If we have a better/different place to keep these issues, let me know. This particular list is on the RESTful specific page, http://wiki.opensocial-templates.org/index.php?title=Restful_Protocol_Issues.

 

It’s a wiki, so other folks on the list should feel free to register and list things they are finding.

[Eiji Kitamura]

Hi Arne,

I've noticed OpenSocial ID spec change is not reflected in "OpenSocial
Specification -- Implementation Version 0.8.1".

Background > Key Concepts > People : A note about user IDs

"The user ID must be alphanumeric (A-Za-z0-9) and must uniquely
identify the user in a container."

should be something like

"The user ID must only contain alphanumeric (A-Za-z0-9) characters,
underscore(_), dot(.) or dash(-) and must uniquely identify the user
in a container."

Eiji

2008/9/5 Arne Roomann-Kurrik <kur...@google.com>:

[Brian Eaton]

Gadgets API reference link on
http://www.opensocial.org/Technical-Resources/staging/opensocial-reference
is broken.

Should link to http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadgets-reference08
or maybe http://www.opensocial.org/Technical-Resources/opensocial-spec-v07/gadgets-spec

[Kevin Brown]

On Mon, Sep 8, 2008 at 10:16 AM, Brian Eaton <bea...@google.com> wrote:

Gadgets API reference link on

http://www.opensocial.org/Technical-Resources/staging/opensocial-reference

is broken.

Should link to http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadgets-reference08

Definitely this one. The other one is the 0.7 version.
 

[Joseph Smarr]

I noticed a couple minor omissions from the release notes. Specifically, name.unstructured was renamed to name.formatted and displayName was added as a new top-level (required) field. These changes were a bit buried in the 0.8.1 Portable Contact alignment docs, but Cassie caught and fixed them recently (see https://issues.apache.org/jira/browse/SHINDIG-576) so can someone please update the docs/spec accordingly?

 

Thanks! js

On Thu, Sep 4, 2008 at 6:47 PM, Arne Roomann-Kurrik <kur...@google.com> wrote:

[Scott Seely]

Here is the updated schema for the Restful Protocol spec.

 

Thanks for the catch!

 

Scott Seely

architect

email  sse...@myspace.com

 

 

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Joseph Smarr

Sent: Monday, September 08, 2008 8:33 PM
To: opensocial-an...@googlegroups.com

[yoichiro]

Hi Arne,

In 8.2 chapter of "Activities - RPC Protocol", I seem that appid is
missing for parameters of the get operation. I think that it should be
added because it exists at same operation in RESTful API.

Please consider my thinking.

Regards,
Yoichiro

On Sep 5, 10:47 am, "Arne Roomann-Kurrik" <kur...@google.com> wrote:
> Updated versions of the spec docs are now staged for review on
> opensocial.org:
>

> OpenSocial Release Noteshttp://www.opensocial.org/Technical-Resources/staging/opensocial-rele...
>
> OpenSocial Specification -- Implementation Version 0.8.1http://www.opensocial.org/Technical-Resources/staging/opensocial-spec...
>
> opensocial-referencehttp://www.opensocial.org/Technical-Resources/staging/opensocial-refe...
>
> Restful Protocolhttp://www.opensocial.org/Technical-Resources/staging/restful-protocol
>
> RPC Protocolhttp://www.opensocial.org/Technical-Resources/staging/rpc-protocol

[Arne Roomann-Kurrik]

Thanks for the feedback on the draft documents!  We've gone over the issues and have added all the feedback into the opensocial-templates wiki (http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Issues), and then split changes into two categories:

Green (fixes we will make to the documentation right away):

• [Release Notes #1] name.formatted and displayName
• [Specification #1] Misc. typos and wording updates
  
• [Specification #2] Include non alphanumeric chars in user ID 
• [JS Reference #1] Broken link to Gadgets API Reference
  
• [Restful #9] XRDS type for Activities is incorrect
  
• [Restful #10] Schema issues
  
• [Restful #12] Add XML examples to section 2
  
• [Restful #13] Schema is missing accepted changes 
• [RPC #2] Change RPC Batch return code from 200 OK to 207 Multi-Status
  

Yellow (needs consensus before we will make modifications):

• [Restful #1] Align the reference / REST implementation, Singular Person Fields
  
• [Restful #2] Align the reference / REST implementation, Plural Person Fields
  
• [Restful #3] Align the reference / REST implementation, Missing Person Fields
  
• [Restful #4] Align the reference / REST implementation, Name Fields
  
• [Restful #5] Align the reference / REST implementation, Address Fields
  
• [Restful #6] Align the reference / REST implementation, Organization Fields
  
• [Restful #7] Align the reference / REST implementation, Account Fields
  
• [Restful #8] Include http status code table 
• [Restful #11] Host schema at correct url 
• [RPC #1] Include http status code table
  
• [RPC #3] Add appID as get parameter 

If anything has been left out, please add it to the wiki and respond to this thread.

As a note, it seems like the "Align the reference / REST implementation" issues are on hold for 0.9, to make the JavaScript fields match PortableContacts.  Is this correct, Scott?  If so, I'll change the status to Red (will not implement for 0.8.1).

~Arne

[Scott Seely]

Arne,

 

From my point of view, the alignment of REST/reference/PortableContacts can be postponed until post 0.8.1.

 

Scott Seely

architect

email  sse...@myspace.com

 

 

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Arne Roomann-Kurrik
Sent: Thursday, September 11, 2008 12:27 PM
To: opensocial-an...@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: Draft spec documents for 0.8.1 now staged at opensocial.org

 

Thanks for the feedback on the draft documents!  We've gone over the issues and have added all the feedback into the opensocial-templates wiki (http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Issues), and then split changes into two categories:

[Joseph Smarr]

Scott/all-the alignment of OpenSocial RESTful APIs and PortableContacts is already complete, and it's definitely for 0.8.1. In fact, it's already implemented in shindig in both java and php and is already live on MySpace, hi5, plaxo, etc. I believe the consensus was to wait on updating the JavaScript to match until 0.9, to make sure this change isn't too jarring to gadget developers in the short term (essentially, the REST API changes now, but the JavaScript will provide a compatibility layer for just a bit), but we definitely all agreed to get the aligned REST API out there for 0.8.1. We had great success demoing a bunch of 0.8.1 implementations yesterday at the Portable Contacts Summit, and David Glazer, Kevin Marks, Paul Lindner, Paul Walker, etc. were all there and very happy to see this progress, so I really think we can't put on it now. :)

 

Thanks, js

[Dan Peterson]

I agree with Joseph -- if there are clarification issues needed for the OpenSocial REST / PortableContacts alignment, we should walk through each of them (thanks Scott for digging in deep) -- which is consistent with my understanding of the current plan for record.

-Dan

[Scott Seely]

It looks like I was unclear here. Let’s try again: The REST/PortableContacts relationship is clearly aligned for 0.8.1. I was just acknowledging Louis Ryan’s question of whether to postpone the REST/JS work until post 0.8.1 so that we wind up in this state for 0.9:

 

PortableContacts aligned with REST aligned with JS.

 

Sorry for the confusion.

[Arne Roomann-Kurrik]

Yes, sorry for not being clearer that the issues I was referring to were JavaScript related only. 

Things I would still like to clear with this group:

• [Restful #8] Include http status code table
  

• [RPC #1] Include http status code table

As discussed here: http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/5f36d131b1e76457# - Can we get some +1s on that thread?  Having explicit status codes in the spec removes an area where containers may go out of sync in their implementations.

• [Restful #11] Host schema at correct url
  

http://wiki.opensocial-templates.org/index.php?title=Restful_Protocol_Issues#Host_schema_at_correct_url
Is there consensus that it would be useful to host the schema at ns.opensocial.org?

• [RPC #3] Add appID as get parameter
  

http://wiki.opensocial-templates.org/index.php?title=RPC_Protocol_Issues#Add_appID_as_get_parameter
A small proposal to align the RESTful and RPC protocols, but one that I don't think was reviewed by the discussion list.  I'm +1 for including the appId, but just wanted some more +1s.

~Arne

[Ram]

Hi All,

I have one doubt about portablecontacts specification for OpenSocial.

Gender is an enum field in OpenSocial spec 0.8 like other fields
Drinker,smoker etc.

In protablecontacts specification at http://portablecontacts.net/draft-spec.html#anchor17

all the other fields except Gender is left as they are in OpenSocial
spec.

"<i>The following additional Singular Fields are defined, based on
their specification in OpenSocial [OpenSocial] (Panzer, J.,
“OpenSocial 0.8 RESTful API Specification,” .): aboutMe, bodyType,
currentLocation, drinker, ethnicity, fashion, happiestWhen, humor,
livingArrangement, lookingFor, profileSong, profileVideo,
relationshipStatus, religion, romance, scaredOf, sexualOrientation,
smoker, and status.</i>"

Now Gender will be no more an enum rest all does. Till the
portablecontacts came into picture all the gadgets were using like
(opensocial.Person.Field.GENDER).getDisplayValue() as it was coming in
response "gender":{"displayValue":"male","key":"MALE"}
but after portable contacts it is coming "gender":"male".

Now my doubt is, are we aware of the fact that a number of gadgets
might be using Gender field already and they need to change their
code.

On Sep 12, 9:47 pm, "Arne Roomann-Kurrik" <kur...@google.com> wrote:
> Yes, sorry for not being clearer that the issues I was referring to were
> JavaScript related only.
>
> Things I would still like to clear with this group:
>

>    - [Restful #8] Include http status code table
>    - [RPC #1] Include http status code table
>
> As discussed here:http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

> Can we get some +1s on that thread?  Having explicit status codes in
> the
> spec removes an area where containers may go out of sync in their
> implementations.
>

>    - [Restful #11] Host schema at correct url
>
> http://wiki.opensocial-templates.org/index.php?title=Restful_Protocol...

> Is there consensus that it would be useful to host the schema at
> ns.opensocial.org?
>

>    - [RPC #3] Add appID as get parameter
>
> http://wiki.opensocial-templates.org/index.php?title=RPC_Protocol_Iss...

> A small proposal to align the RESTful and RPC protocols, but one that I
> don't think was reviewed by the discussion list.  I'm +1 for including the
> appId, but just wanted some more +1s.
>
> ~Arne
>
>
>
> On Fri, Sep 12, 2008 at 9:01 AM, Scott Seely <SSe...@myspace.com> wrote:
> >  It looks like I was unclear here. Let's try again: The
> > REST/PortableContacts relationship is clearly aligned for 0.8.1. I was
> > just acknowledging Louis Ryan's question of whether to postpone the REST/JS
> > work until post 0.8.1 so that we wind up in this state for 0.9:
>
> > PortableContacts aligned with REST aligned with JS.
>
> > Sorry for the confusion.
>
> > Scott Seely
>
> > architect
>

> > *email*  sse...@myspace.com
>
> > *From:* opensocial-an...@googlegroups.com [mailto:
> > opensocial-an...@googlegroups.com] *On Behalf Of *Dan Peterson
> > *Sent:* Friday, September 12, 2008 8:48 AM
>
> > *To:* opensocial-an...@googlegroups.com
> > *Subject:* [opensocial-and-gadgets-spec] Re: Draft spec documents for

> > 0.8.1 now staged at opensocial.org
>
> > I agree with Joseph -- if there are clarification issues needed for the
> > OpenSocial REST / PortableContacts alignment, we should walk through each of
> > them (thanks Scott for digging in deep) -- which is consistent with my
> > understanding of the current plan for record.
>
> > -Dan
>
> > On Fri, Sep 12, 2008 at 8:28 AM, Joseph Smarr <jsm...@gmail.com> wrote:
>
> > Scott/all-the alignment of OpenSocial RESTful APIs and PortableContacts is
> > already complete, and it's definitely for 0.8.1. In fact, it's already
> > implemented in shindig in both java and php and is already live on MySpace,
> > hi5, plaxo, etc. I believe the consensus was to wait on updating the
> > JavaScript to match until 0.9, to make sure this change isn't too jarring to
> > gadget developers in the short term (essentially, the REST API changes now,
> > but the JavaScript will provide a compatibility layer for just a bit), but

> > we definitely all agreed to get the aligned REST API out there for 0.8.1.We had great success demoing a bunch of 0.8.1 implementations yesterday at

> > the Portable Contacts Summit, and David Glazer, Kevin Marks, Paul Lindner,
> > Paul Walker, etc. were all there and very happy to see this progress, so I
> > really think we can't put on it now. :)
>
> > Thanks, js
>
> > On Thu, Sep 11, 2008 at 1:01 PM, Scott Seely <SSe...@myspace.com> wrote:
>
> > Arne,
>
> > From my point of view, the alignment of REST/reference/PortableContacts can
> > be postponed until post 0.8.1.
>
> > Scott Seely
>
> > architect
>

> > *email*  sse...@myspace.com
>
> > *From:* opensocial-an...@googlegroups.com [mailto:
> > opensocial-an...@googlegroups.com] *On Behalf Of *Arne
> > Roomann-Kurrik
> > *Sent:* Thursday, September 11, 2008 12:27 PM
>
> > *To:* opensocial-an...@googlegroups.com
> > *Subject:* [opensocial-and-gadgets-spec] Re: Draft spec documents for

> > 0.8.1 now staged at opensocial.org
>
> > Thanks for the feedback on the draft documents!  We've gone over the issues
> > and have added all the feedback into the opensocial-templates wiki (
> >http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Issues),
> > and then split changes into two categories:
>
> > Green (fixes we will make to the documentation right away):
>

> >    - [Release Notes #1] name.formatted and displayName
> >    - [Specification #1] Misc. typos and wording updates
> >    - [Specification #2] Include non alphanumeric chars in user ID
> >    - [JS Reference #1] Broken link to Gadgets API Reference
> >    - [Restful #9] XRDS type for Activities is incorrect
> >    - [Restful #10] Schema issues
> >    - [Restful #12] Add XML examples to section 2
> >    - [Restful #13] Schema is missing accepted changes
> >    - [RPC #2] Change RPC Batch return code from 200 OK to 207 Multi-Status

>
> > Yellow (needs consensus before we will make modifications):
>

> >    - [Restful #1] Align the reference / REST implementation, Singular
> >    Person Fields
> >    - [Restful #2] Align the reference / REST implementation, Plural Person
> >    Fields
> >    - [Restful #3] Align the reference / REST implementation, Missing
> >    Person Fields
> >    - [Restful #4] Align the reference / REST implementation, Name Fields
> >    - [Restful #5] Align the reference / REST implementation, Address
> >    Fields
> >    - [Restful #6] Align the reference / REST implementation, Organization
> >    Fields
> >    - [Restful #7] Align the reference / REST implementation, Account
> >    Fields
> >    - [Restful #8] Include http status code table
> >    - [Restful #11] Host schema at correct url
> >    - [RPC #1] Include http status code table
> >    - [RPC #3] Add appID as get parameter

[Scott Seely]

FWIW, I think that the choice to make gender open ended is the right choice. OpenSocial aims to serve a large number of communities. For some communities (example: Bi/Lesbian/Gay/Transgender), male/female is not sufficient. For a list of a few missing terms, see http://en.wikipedia.org/wiki/Gender_identity.

We also have implied use cases with intersex individuals (http://en.wikipedia.org/wiki/Intersexuality). Not all of us have only XX and XY chromosomal pairs.

Because of these two reasons, I figured that this was why the PortableContacts spec chose to move gender to be a string. Gender as a string allows sites to have a mechanism where people can self identify their gender outside of male/female. Even if my guess is wrong about WHY gender is a string, I think that PortableContacts made the right choice for gender.

Scott Seely
architect
email  sse...@myspace.com

[Joseph Smarr]

Ram-one of the explicit changes to OpenSocial in 0.8.1 to align it with PortableContacts was to *remove* the enum from gender and make it a string. This was widely agreed upon, and clients can still look for the "canonical values" "male" and "female" if they want to treat it like an enum, but this way gender is just a simple string, and we felt that since it was such a common and simple field, it was important to keep it this simple.

 

So yes, some JavaScript code may have to change (unless they decide to re-cast it as an enum at the JavaScript layer), but again we felt this was worth it in the long term.

 

Thanks, js

[Cassie]

1. The javascript code does not have to change for gender. The opensocial javascript spec is not changing at all right now. All containers backing their javascript apis with the restful/rpc apis need to take the server output and translate it into the appropriate output for the opensocial js apis. See Shindig for an example of this if you have questions on implementation.

The js apis themselves may or may not be changed for 0.9 dependening on what this list decides.


2. Scott - enums in opensocial js are designed for flexibility. If someone was not male or female then their gender would have been {displayValue : 'purple',  key: 'null'} where purple was their gender. So, opensocial js does allow you to go outside the standard canonical values.

The portable contacts string value does the same thing... just in a different way. Gender can be 'male', 'female' or 'purple'. In opensocial js we chose enums at the time so that the canonical values were very clear (and also two allow different display values for the same canonical value). However, both ways are perfectly equal - its just a style thing.


3. I'm going to pull the appId question into a separate thread so we can decide on it quickly. (It's getting buried in this thread)


- Cassie

[Scott Seely]

Found a few more bugs in the XSD. So that it is easier for people to track changes and see where the delta’s are, I’ve posted this to http://wiki.opensocial-templates.org/index.php?title=RESTFul_Schema. The delta’s between what we had and the various bug fixes in the schema can be seen by looking at this delta view:

 

http://wiki.opensocial-templates.org/index.php?title=RESTFul_Schema&diff=384&oldid=383

[scottk]

Release Notes are now updated with these 2 changes.

Thanks,
Scott

On Sep 8, 8:32 pm, "Joseph Smarr" <jsm...@gmail.com> wrote:
> I noticed a couple minor omissions from the release notes. Specifically,
> name.unstructured was renamed to name.formatted and displayName was added as
> a new top-level (required) field. These changes were a bit buried in the
> 0.8.1 Portable Contact alignment docs, but Cassie caught and fixed them

> recently (seehttps://issues.apache.org/jira/browse/SHINDIG-576) so can

> someone please update the docs/spec accordingly?
>
> Thanks! js
>
> On Thu, Sep 4, 2008 at 6:47 PM, Arne Roomann-Kurrik <kur...@google.com>wrote:
>
> >  Updated versions of the spec docs are now staged for review on
> > opensocial.org:
>
> > OpenSocial Release Notes

> >http://www.opensocial.org/Technical-Resources/staging/opensocial-rele...

>
> > OpenSocial Specification -- Implementation Version 0.8.1
>

> >http://www.opensocial.org/Technical-Resources/staging/opensocial-spec...
>
> > opensocial-reference
> >http://www.opensocial.org/Technical-Resources/staging/opensocial-refe...

[scottk]

>I've noticed OpenSocial ID spec change is not reflected in "OpenSocial
>Specification -- Implementation Version 0.8.1".
>Background > Key Concepts > People : A note about user IDs
>"The user ID must be alphanumeric (A-Za-z0-9) and must uniquely
>identify the user in a container."
>should be something like
>"The user ID must only contain alphanumeric (A-Za-z0-9) characters,
>underscore(_), dot(.) or dash(-) and must uniquely identify the user
>in a container."

This has now been fixed in the spec.

Thanks,
Scott

On Sep 5, 11:10 pm, "Eiji Kitamura" <agek...@gmail.com> wrote:
> Hi Arne,
>
> I've noticed OpenSocial ID spec change is not reflected in "OpenSocial
> Specification -- Implementation Version 0.8.1".
>
> Background > Key Concepts > People : A note about user IDs
>
> "The user ID must be alphanumeric (A-Za-z0-9) and must uniquely
> identify the user in a container."
>
> should be something like
>
> "The user ID must only contain alphanumeric (A-Za-z0-9) characters,
> underscore(_), dot(.) or dash(-) and must uniquely identify the user
> in a container."
>
> Eiji
>
> 2008/9/5 Arne Roomann-Kurrik <kur...@google.com>:> Updated versions of the spec docs are now staged for review on
> > opensocial.org:
> > OpenSocial Release Notes

> >http://www.opensocial.org/Technical-Resources/staging/opensocial-rele...

> > OpenSocial Specification -- Implementation Version 0.8.1

> >http://www.opensocial.org/Technical-Resources/staging/opensocial-spec...
> > opensocial-reference
> >http://www.opensocial.org/Technical-Resources/staging/opensocial-refe...

[Dan Peterson]

Hey Scott,

I believe we're all done with all of the comments on 0.8.1, so we should go ahead and move this stuff out of the /staged/ folder, and make it official.

Two small clarification comments on the release notes:

1) http://www.opensocial.org/Technical-Resources/opensocial-release-notes

"This document describes the significant additions and changes in version 0.8 of the OpenSocial API. All features are covered in the API Reference (v0.8)."

-->

"This section describes the significant additions and changes in version 0.8 of the OpenSocial API. All JavaScript features are covered in the API Reference (v0.8)."

2) http://www.opensocial.org/Technical-Resources/staging/opensocial-release-notes

At the top of the 0.8.1 section, similar to the text with the other releases, I'd suggest something to the effect of:

"Version 0.8.1 was primarily focused on changes to the server to server protocols introduced in v0.8: the person schema has been aligned with the Portable Contacts effort and an optional RPC proposal has been introduced as well."

Totally open to edits,

-Dan

On Thu, Sep 4, 2008 at 6:47 PM, Arne Roomann-Kurrik <kur...@google.com> wrote: