Hey folks,Now that OpenSocial v0.8.1 is effectively wrapped up, it seems prudent for us to get the ball rolling with OpenSocial v0.9 -- especially since there's already been a lot of discussion about potential inclusions to date.For those new to the spec process -- welcome! The following (draft) introductory document explains how the spec evolves: http://www.opensocial.org/Technical-Resources/spec-processLet me recap what I've seen as highly likely components for v0.9:
- Clean gadget XML spec -- to remove all ambiguity in XML parsing and processing
To help make sure that proposals don’t get forgotten, Chris Chabot, Dan Peterson, and I will be working together to make sure that the list of proposals is maintained. During this milestone, you’ll be seeing messages from us to help make sure that proposals continue to move along. We’ve gone over the various threads since 0.8.1 launched and have tried to capture the set of proposals brought forth so far. It is possible that something got missed. If you proposed something, please check http://spreadsheets.google.com/ccc?key=pLSOqcf1mK9XQ-OmytqL3Qw&hl=en. If the proposal isn’t on this list, let us know and we’ll get it added quickly.
From:
opensocial-an...@googlegroups.com
[mailto:opensocial-an...@googlegroups.com] On Behalf Of Dan
Peterson
Sent: Wednesday, October 01, 2008 12:26 AM
To: OpenSocial and Gadgets Specification Discussion
Subject: [opensocial-and-gadgets-spec] Kicking off OpenSocial v0.9
Hey folks,
Now that OpenSocial v0.8.1 is effectively wrapped up, it seems prudent for us to get the ball rolling with OpenSocial v0.9 -- especially since there's already been a lot of discussion about potential inclusions to date.
For those new to the spec process -- welcome! The following (draft) introductory document explains how the spec evolves: http://www.opensocial.org/Technical-Resources/spec-process
Let me recap what I've seen as highly likely components for v0.9:
· Clean gadget XML spec -- to remove all ambiguity in XML parsing and processing
· Fetch/Cache/Invalidate Model
· OpenSocial Templates [Prototype running and implemented in Shindig -- http://ostemplates-demo.appspot.com/]
o Templating syntax and structure
§ http://www.opensocial.org/Technical-Resources/opensocial-templates-spec
o Data pipelining
§ http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Data_Pipelining
o OSML for roughly 10 tags as defined on:
§ http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup
In addition, I personally think the spec can be improved in some other ways as well:
· Views standard (enums?)
o Strongly specify mappings from view name to constraints
§ view sizing, expected audience, usage of JavaScript/templates/Caja, etc.
· Caja usage standard
o Strongly specify how the app and container negotiate about using Caja
§ Since some containers will want it sooner rather than later, we need to nail this down to keep XML files portable
§ Is it a require feature? Can it be optional?
· More inquisition
o Add more functions to allow developers to programmatically retrieve configuration settings
§ Size of AppData, rate limits on viral channels, Caja usage, etc.
· Metadata for AppData
o Provide more metadata: who wrote it, when they wrote it
o Perhaps add a "type" to the key/value pair
This has been added to the list.
Ian
Splitting off a new thread to keep the discussion compartmentalized:
Here is the schema that represents the repeating elements found in the PortableContacts API. The xsd:sequence is necessary on person to allow for schema validation to allow for looser processing of repeated elements. I’ve run this against the big XML example in the portable contacts spec (http://portablecontacts.net/draft-spec.html#anchor18) and everything validated. If we can get this to a point where we have something we agree is correct, we can then move on to getting the XSD in the REST API aligned with PC.
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:tns="http://ns.portablecontacts.net/2008/portablecontacts" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://ns.portablecontacts.net/2008/portablecontacts">
<xs:complexType name="name">
<xs:all>
<xs:element name="familyName" type="xs:string" minOccurs="0" />
<xs:element name="givenName" type="xs:string" minOccurs="0" />
</xs:all>
</xs:complexType>
<xs:complexType name="valueType">
<xs:all>
<xs:element name="value" type="xs:string" minOccurs="0" />
<xs:element name="type" type="xs:string" minOccurs="0" />
<xs:element name="primary" type="xs:string" minOccurs="0" />
</xs:all>
</xs:complexType>
<xs:complexType name="address">
<xs:all>
<xs:element name="type" type="xs:string" minOccurs="0" />
<xs:element name="streetAddress" type="xs:string" minOccurs="0" />
<xs:element name="locality" type="xs:string" minOccurs="0" />
<xs:element name="region" type="xs:string" minOccurs="0" />
<xs:element name="postalCode" type="xs:string" minOccurs="0" />
<xs:element name="country" type="xs:string" minOccurs="0" />
<xs:element name="formatted" type="xs:string" minOccurs="0" />
</xs:all>
</xs:complexType>
<xs:complexType name="organization">
<xs:all>
<xs:element name="name" type="xs:string" minOccurs="0" />
<xs:element name="title" type="xs:string" minOccurs="0" />
</xs:all>
</xs:complexType>
<xs:complexType name="account">
<xs:all>
<xs:element name="domain" type="xs:string" minOccurs="0" />
<xs:element name="userid" type="xs:string" minOccurs="0" />
</xs:all>
</xs:complexType>
<xs:complexType name="person">
<xs:sequence>
<xs:element name="id" type="xs:string" minOccurs="0" />
<xs:element name="displayName" type="xs:string" minOccurs="0" />
<xs:element name="birthday" type="xs:string" minOccurs="0" />
<xs:element name="gender" type="xs:string" minOccurs="0" />
<xs:element name="drinker" type="xs:string" minOccurs="0" />
<xs:element name="accounts" type="tns:account" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="addresses" type="tns:address" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="emails" type="tns:valueType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="ims" type="tns:valueType" minOccurs="0" />
<xs:element name="name" type="tns:name" minOccurs="0" />
<xs:element name="organizations" type="tns:organization" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="phoneNumbers" type="tns:valueType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="photos" type="tns:valueType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="tags" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="urls" type="tns:valueType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="response">
<xs:sequence>
<xs:element name="startIndex" type="xs:string" minOccurs="0" />
<xs:element name="itemsPerPage" type="xs:string" minOccurs="0" />
<xs:element name="totalResults" type="xs:string" minOccurs="0" />
<xs:element name="entry" type="tns:person" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="response" type="tns:response"/>
</xs:schema>
-----Original Message-----
From: Scott Seely
Sent: Thursday, October 23, 2008 10:29 AM
To: opensocial-an...@googlegroups.com
Subject: RE: [opensocial-and-gadgets-spec] Re: Kicking off OpenSocial v0.9
At this point in time, PC doesn't appear to have a schema. If we are using PC as the ideal, we need to develop a schema that is in agreement between the two. We already know that we need to reconcile the JS API and REST (see http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/94fcfba9683ef6cd/).
Reconciling REST with PC seems to be the first order item, followed by REST and JSAPI. Does this sound reasonable?
-----Original Message-----
From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Ian Boston
Sent: Thursday, October 23, 2008 10:20 AM
To: opensocial-an...@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: Kicking off OpenSocial v0.9
Dan,
Missed two items on the schema header (highlighted)
<xs:schema xmlns:tns="http://ns.portablecontacts.net/2008/portablecontacts" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://ns.portablecontacts.net/2008/portablecontacts"
xmlns="http://ns.portablecontacts.net/2008/portablecontacts"
attributeFormDefault="qualified" elementFormDefault="qualified">
For these things, please look through the list of items at http://spreadsheets.google.com/ccc?key=pLSOqcf1mK9XQ-OmytqL3Qw&hl=en. If the item you want is not on the list, you need to create a separate thread with a high level proposal so that we can zero in on the specifics.
Ropu and Kevin—can you kick off the separate threads with more fully formed ideas? This will make tracking much easier.
From:
opensocial-an...@googlegroups.com
[mailto:opensocial-an...@googlegroups.com] On Behalf Of Ropu
Sent: Thursday, October 23, 2008 6:19 PM
To: opensocial-an...@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: Kicking off OpenSocial v0.9
5. To retrieve and modify User Status
On Thu, Oct 23, 2008 at 6:17 PM, Kevin Marks <kevin...@gmail.com> wrote:
four areas that I think would benefit from some discussion in this group, whether for 0.9 or beyond:
On Wed, Oct 1, 2008 at 12:25 AM, Dan Peterson <dpet...@google.com> wrote:
Hey folks,
Now that OpenSocial v0.8.1 is effectively wrapped up, it seems prudent for us to get the ball rolling with OpenSocial v0.9 -- especially since there's already been a lot of discussion about potential inclusions to date.
For those new to the spec process -- welcome! The following (draft) introductory document explains how the spec evolves: http://www.opensocial.org/Technical-Resources/spec-process
Let me recap what I've seen as highly likely components for v0.9:
· Clean gadget XML spec -- to remove all ambiguity in XML parsing and processing
· Fetch/Cache/Invalidate Model
- Fell out of the discussion related to templates and type="proxied"
- Should help improve performance
- Early proposal conversation: http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/fc2dac657f14fc5f
· OpenSocial Templates [Prototype running and implemented in Shindig -- http://ostemplates-demo.appspot.com/]
o Templating syntax and structure
§ http://www.opensocial.org/Technical-Resources/opensocial-templates-spec
o Data pipelining
§ http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Data_Pipelining
o OSML for roughly 10 tags as defined on:
§ http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup
In addition, I personally think the spec can be improved in some other ways as well:
· Views standard (enums?)
o Strongly specify mappings from view name to constraints
§ view sizing, expected audience, usage of JavaScript/templates/Caja, etc.
· Caja usage standard
o Strongly specify how the app and container negotiate about using Caja
§ Since some containers will want it sooner rather than later, we need to nail this down to keep XML files portable
§ Is it a require feature? Can it be optional?
· More inquisition
o Add more functions to allow developers to programmatically retrieve configuration settings
§ Size of AppData, rate limits on viral channels, Caja usage, etc.
· Metadata for AppData
o Provide more metadata: who wrote it, when they wrote it
o Perhaps add a "type" to the key/value pair
With that, what do YOU want in OpenSocial v0.9? OpenSocial itself is a spec that is defined right here on this public mailing list. Anyone can propose an addition, anyone can vote/comment on proposals, so get involved and provide comments to make OpenSocial better.
In terms of timing, consistent with the default timeline in the process doc, I propose we should plan to wrap up 0.9 -- fully baked! -- in ~12 weeks (concluding in mid-December or so).
Let's aim to get all ideas on the table by Friday, October 10 (certainly, it is fine to go into deep details of any particular component before then).
Cheers,
-Dan
The only response type in PC is a person, hence it makes sense to
have an "entry" element being the contents of the person object. The
below is the section from the PC XSD.
In OS we have activity, message, person, group, appdata as response
types, all enclosed by the single containing element entry.
so a PC response looks like
<response>
...
<entry>
<id></id>
<displayName></displayName>
...
</entry>
<entry>
...
</entry>
</response>
But the 0.8.1 spec does not clearly state what the OS response should
be like... it could be
<response>
...
<entry>
<id></id>
<displayName></displayName>
...
</entry>
<entry>
...
</entry>
</response>
or
<response>
...
<entry>
<person>
<id></id>
<displayName></displayName>
...
</person>
</entry>
<entry>
...
</entry>
</response>
but could also be interpreted as
<?xml version="1.0" encoding="UTF-8"?>
<response>
<startIndex>0</startIndex>
<itemsPerPage>20</itemsPerPage>
<totalResults>721</totalResults>
<person>
<isOwner></isOwner>
<isViewer></isViewer>
<displayName>Bruno rovagnati</displayName>
<id>5</id>
<thumbnailUrl>http://www.partuza.nl/images/people/5.96x96.jpg</
thumbnailUrl>
<profileUrl>http://www.partuza.nl/profile/5</profileUrl>
</person>
...
or
<?xml version="1.0" encoding="UTF-8"?>
<response>
<startIndex>0</startIndex>
<itemsPerPage>20</itemsPerPage>
<totalResults>721</totalResults>
<entry>
<person>
<isOwner></isOwner>
<isViewer></isViewer>
<displayName>Bruno rovagnati</displayName>
<id>5</id>
<thumbnailUrl>http://www.partuza.nl/images/people/5.96x96.jpg</
thumbnailUrl>
<profileUrl>http://www.partuza.nl/profile/5</profileUrl>
</person>
</entry>
...
I am really struggling to know that the 'official' shema is, and I
dont want to start inventing one.
IMHO the representation should be
<response>
<startIndex>0</startIndex>
<itemsPerPage>20</itemsPerPage>
<totalResults>721</totalResults>
<entry>
<person>
....
</person>
</entry>
which would align the xml format with the atom format, and align the
single response with the multiple response..... but obviously, there
is now tension between the XML and JSON.
Ian
is used for responses of person
and
activity
group
AFAIK, XSD doesn't allow one element to have multiple types at the
same XPath location in the same namespace ?
I have a working XSD and passing unit tests in shindig at http://
svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api/src/
test/resources/org/apache/shindig/social/opensocial/util/
opensocial.xsd which I have just committed.
I thought it better to create and test a real xsd to make certain it
worked.
Ian