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.
In addition, I personally think the spec can be improved in some other ways as well:
- Views standard (enums?) - Strongly specify mappings from view name to constraints - view sizing, expected audience, usage of JavaScript/templates/Caja, etc. - Caja usage standard - 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 - 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 - Provide more metadata: who wrote it, when they wrote it - 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).
On Wed, Oct 1, 2008 at 12:25 AM, Dan Peterson <dpeter...@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.
> In addition, I personally think the spec can be improved in some other ways > as well:
> - Views standard (enums?) > - Strongly specify mappings from view name to constraints > - view sizing, expected audience, usage of > JavaScript/templates/Caja, etc. > - Caja usage standard > - 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 > - 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 > - Provide more metadata: who wrote it, when they wrote it > - 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).
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-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@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.
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).
Thanks for this effort. It sure is a good way to track this in a
spreadsheet. My proposal for Albums API is missing from the list. I will be
posting an updated link to the proposal soon (today/tomorrow). Can you
include that in this list?
On Wed, Oct 22, 2008 at 10:42 PM, Scott Seely <sSe...@myspace.com> wrote:
> 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-and-gadgets-spec@googlegroups.com [mailto:
> opensocial-and-gadgets-spec@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.
> 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
--
Jimmy Buffett - "Indecision may or may not be my problem."
From: opensocial-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Shishir Birmiwal
Sent: Thursday, October 23, 2008 9:20 AM
To: opensocial-and-gadgets-spec@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: Kicking off OpenSocial v0.9
Hey,
Thanks for this effort. It sure is a good way to track this in a spreadsheet. My proposal for Albums API is missing from the list. I will be posting an updated link to the proposal soon (today/tomorrow). Can you include that in this list?
Thanks,
Shishir
On Wed, Oct 22, 2008 at 10:42 PM, Scott Seely <sSe...@myspace.com> wrote:
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-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@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.
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
--
Jimmy Buffett - "Indecision may or may not be my problem."
Dan, I think we have to do something about the XSD for opensocial REST/XML as its a long way from both the JSON and PortableContacts at the moment. Joseph Smarr and me had a long thread on the subject that was resolved ready for 0.9 but that was just one area, and we haven't even thought about backwards compat with 0.8.1 if its even required.
> 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.
> 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 > http://groups.google.com/group/opensocial-and-gadgets-spec/msg/ > b61cc49ec9ecac59?hl=en > Draft proposal - http://docs.google.com/View?id=dgf9q4v4_2wkcbvn3z > Gadget type="proxied" > http://groups.google.com/group/opensocial-and-gadgets-spec/ > browse_thread/thread/c67095188a3614f0/b8d59f6895b45b74 > 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/] > Templating syntax and structure > http://www.opensocial.org/Technical-Resources/opensocial-templates- > spec > Data pipelining > http://wiki.opensocial-templates.org/index.php? > title=OpenSocial_Data_Pipelining > 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?) > Strongly specify mappings from view name to constraints > view sizing, expected audience, usage of JavaScript/templates/Caja, > etc. > Caja usage standard > 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 > 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 > Provide more metadata: who wrote it, when they wrote it > 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).
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_thr...).
Reconciling REST with PC seems to be the first order item, followed by
REST and JSAPI. Does this sound reasonable?
[mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Ian
Boston
Sent: Thursday, October 23, 2008 10:20 AM
To: opensocial-and-gadgets-spec@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: Kicking off OpenSocial v0.9
Dan,
I think we have to do something about the XSD for opensocial REST/XML
as its a long way from both the JSON and PortableContacts at the
moment. Joseph Smarr and me had a long thread on the subject that was
resolved ready for 0.9 but that was just one area, and we haven't
even thought about backwards compat with 0.8.1 if its even required.
Ian
On 1 Oct 2008, at 08:25, Dan Peterson 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.
> 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
> http://groups.google.com/group/opensocial-and-gadgets-spec/msg/ > b61cc49ec9ecac59?hl=en
> Draft proposal - http://docs.google.com/View?id=dgf9q4v4_2wkcbvn3z > Gadget type="proxied"
> http://groups.google.com/group/opensocial-and-gadgets-spec/ > browse_thread/thread/c67095188a3614f0/b8d59f6895b45b74
> 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/]
> Templating syntax and structure
> http://www.opensocial.org/Technical-Resources/opensocial-templates- > spec
> Data pipelining
> http://wiki.opensocial-templates.org/index.php? > title=OpenSocial_Data_Pipelining
> 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?)
> Strongly specify mappings from view name to constraints
> view sizing, expected audience, usage of JavaScript/templates/Caja,
> etc.
> Caja usage standard
> 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
> 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
> Provide more metadata: who wrote it, when they wrote it
> 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).
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.
-----Original Message----- From: Scott Seely Sent: Thursday, October 23, 2008 10:29 AM To: opensocial-and-gadgets-spec@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_thr...).
Reconciling REST with PC seems to be the first order item, followed by REST and JSAPI. Does this sound reasonable?
-----Original Message-----
From: opensocial-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Ian Boston
Sent: Thursday, October 23, 2008 10:20 AM
To: opensocial-and-gadgets-spec@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Re: Kicking off OpenSocial v0.9
Dan,
I think we have to do something about the XSD for opensocial REST/XML
as its a long way from both the JSON and PortableContacts at the
moment. Joseph Smarr and me had a long thread on the subject that was
resolved ready for 0.9 but that was just one area, and we haven't
even thought about backwards compat with 0.8.1 if its even required.
From: opensocial-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Scott Seely
Sent: Thursday, October 23, 2008 11:44 AM
To: opensocial-and-gadgets-spec@googlegroups.com
Subject: [opensocial-and-gadgets-spec] Resolve Schema with Portable Contacts
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.
Is there a larger set of PC sample data that this can be checked
against (preferable real) ? It might expose the detail of areas where
the XSD doesnt work.
I could take it a re-configure the OS bean converters in Shindig to
convert the OS model, but I think that might be jumping the gun.
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.
> -----Original Message-----
> From: Scott Seely
> Sent: Thursday, October 23, 2008 10:29 AM
> To: opensocial-and-gadgets-spec@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-and-gadgets-spec@googlegroups.com
> [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of
> Ian Boston
> Sent: Thursday, October 23, 2008 10:20 AM
> To: opensocial-and-gadgets-spec@googlegroups.com
> Subject: [opensocial-and-gadgets-spec] Re: Kicking off OpenSocial v0.9
> Dan,
> I think we have to do something about the XSD for opensocial REST/XML
> as its a long way from both the JSON and PortableContacts at the
> moment. Joseph Smarr and me had a long thread on the subject that was
> resolved ready for 0.9 but that was just one area, and we haven't
> even thought about backwards compat with 0.8.1 if its even required.
> Ian
> On 1 Oct 2008, at 08:25, Dan Peterson wrote:
On Thu, Oct 23, 2008 at 10:29 AM, Scott Seely <sSe...@myspace.com> wrote:
> 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-and-gadgets-spec@googlegroups.com > [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Ian > Boston > Sent: Thursday, October 23, 2008 10:20 AM > To: opensocial-and-gadgets-spec@googlegroups.com > Subject: [opensocial-and-gadgets-spec] Re: Kicking off OpenSocial v0.9
> Dan, > I think we have to do something about the XSD for opensocial REST/XML > as its a long way from both the JSON and PortableContacts at the > moment. Joseph Smarr and me had a long thread on the subject that was > resolved ready for 0.9 but that was just one area, and we haven't > even thought about backwards compat with 0.8.1 if its even required.
> Ian > On 1 Oct 2008, at 08:25, Dan Peterson 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.
> > 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 > > http://groups.google.com/group/opensocial-and-gadgets-spec/msg/ > > b61cc49ec9ecac59?hl=en > > Draft proposal - http://docs.google.com/View?id=dgf9q4v4_2wkcbvn3z > > Gadget type="proxied" > > http://groups.google.com/group/opensocial-and-gadgets-spec/ > > browse_thread/thread/c67095188a3614f0/b8d59f6895b45b74 > > 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/] > > Templating syntax and structure > > http://www.opensocial.org/Technical-Resources/opensocial-templates- > > spec > > Data pipelining > > http://wiki.opensocial-templates.org/index.php? > > title=OpenSocial_Data_Pipelining > > 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?) > > Strongly specify mappings from view name to constraints > > view sizing, expected audience, usage of JavaScript/templates/Caja, > > etc. > > Caja usage standard > > 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 > > 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 > > Provide more metadata: who wrote it, when they wrote it > > 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).
four areas that I think would benefit from some discussion in this group, whether for 0.9 or beyond:
1. A common standard for user-uploaded/shared media including pictures, audio and video (many apps want this, many containers have their own APIs) 2. A common standard for asking for or offering payment (several containers offer this; some 3rd parties have also built this) 3. A richer API for Activity Streams - currently we only offer read/write on a per-app basis - many containers also generate public streams that are accessible, and could be improved by having common ways to refelect the media elements we already enable to be posted. 4. Common models for writing location information to a container as well as reading it, given the growth of mobile appliactions and geodata.
On Wed, Oct 1, 2008 at 12:25 AM, Dan Peterson <dpeter...@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.
> In addition, I personally think the spec can be improved in some other ways > as well:
> - Views standard (enums?) > - Strongly specify mappings from view name to constraints > - view sizing, expected audience, usage of > JavaScript/templates/Caja, etc. > - Caja usage standard > - 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 > - 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 > - Provide more metadata: who wrote it, when they wrote it > - 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).
On Thu, Oct 23, 2008 at 6:17 PM, Kevin Marks <kevinma...@gmail.com> wrote: > four areas that I think would benefit from some discussion in this group, > whether for 0.9 or beyond:
> 1. A common standard for user-uploaded/shared media including pictures, > audio and video (many apps want this, many containers have their own APIs) > 2. A common standard for asking for or offering payment (several > containers offer this; some 3rd parties have also built this) > 3. A richer API for Activity Streams - currently we only offer > read/write on a per-app basis - many containers also generate public streams > that are accessible, and could be improved by having common ways to refelect > the media elements we already enable to be posted. > 4. Common models for writing location information to a container as > well as reading it, given the growth of mobile appliactions and geodata.
> On Wed, Oct 1, 2008 at 12:25 AM, Dan Peterson <dpeter...@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.
>> In addition, I personally think the spec can be improved in some other >> ways as well:
>> - Views standard (enums?) >> - Strongly specify mappings from view name to constraints >> - view sizing, expected audience, usage of >> JavaScript/templates/Caja, etc. >> - Caja usage standard >> - 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 >> - 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 >> - Provide more metadata: who wrote it, when they wrote it >> - 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).
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-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Ropu
Sent: Thursday, October 23, 2008 6:19 PM
To: opensocial-and-gadgets-spec@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 <kevinma...@gmail.com> wrote:
four areas that I think would benefit from some discussion in this group, whether for 0.9 or beyond:
1. A common standard for user-uploaded/shared media including pictures, audio and video (many apps want this, many containers have their own APIs)
2. A common standard for asking for or offering payment (several containers offer this; some 3rd parties have also built this)
3. A richer API for Activity Streams - currently we only offer read/write on a per-app basis - many containers also generate public streams that are accessible, and could be improved by having common ways to refelect the media elements we already enable to be posted.
4. Common models for writing location information to a container as well as reading it, given the growth of mobile appliactions and geodata.
On Wed, Oct 1, 2008 at 12:25 AM, Dan Peterson <dpeter...@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.
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).
> From: opensocial-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Scott Seely
> Sent: Thursday, October 23, 2008 11:44 AM
> To: opensocial-and-gadgets-spec@googlegroups.com
> Subject: [opensocial-and-gadgets-spec] Resolve Schema with Portable Contacts
> 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.
>> From: opensocial-and-gadgets-spec@googlegroups.com
>> [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of
>> Scott Seely
>> Sent: Thursday, October 23, 2008 11:44 AM
>> To: opensocial-and-gadgets-spec@googlegroups.com
>> Subject: [opensocial-and-gadgets-spec] Resolve Schema with
>> Portable Contacts
>> 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.
> >> From: opensocial-and-gadgets-spec@googlegroups.com > >> [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of > >> Scott Seely > >> Sent: Thursday, October 23, 2008 11:44 AM > >> To: opensocial-and-gadgets-spec@googlegroups.com > >> Subject: [opensocial-and-gadgets-spec] Resolve Schema with > >> Portable Contacts
> >> 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.
>> >> From: opensocial-and-gadgets-spec@googlegroups.com >> >> [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of >> >> Scott Seely >> >> Sent: Thursday, October 23, 2008 11:44 AM >> >> To: opensocial-and-gadgets-spec@googlegroups.com >> >> Subject: [opensocial-and-gadgets-spec] Resolve Schema with >> >> Portable Contacts
>> >> 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.
I had previously posted an updated xsd for OS0.9, but having done some more implementation against the text of the 0.8.1 version of the spec I can see a conflict in the XSD between OS and PC.
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>
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>
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.
I think it should be <response><entry><displayName> and no <person> but the <entry> is of type person in XML-schema land. That would parallel the JSON and most closely follow the spec. Does that make sense?
On Tue, Nov 4, 2008 at 1:29 AM, Ian Boston <ianbos...@googlemail.com> wrote:
> I had previously posted an updated xsd for OS0.9, but having done > some more implementation against the text of the 0.8.1 version of the > spec I can see a conflict in the XSD between OS and PC.
> 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>
> 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>
> 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.
That does make sense, but my point was <response><entry>
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
> I think it should be <response><entry><displayName> and no <person> > but the <entry> is of type person in XML-schema land. That would > parallel the JSON and most closely follow the spec. Does that make > sense?
> Thanks, js
> On Tue, Nov 4, 2008 at 1:29 AM, Ian Boston > <ianbos...@googlemail.com> wrote:
> I had previously posted an updated xsd for OS0.9, but having done > some more implementation against the text of the 0.8.1 version of the > spec I can see a conflict in the XSD between OS and PC.
> 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>
> 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>
> 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.
> That does make sense, > but my point was > <response><entry>
> 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
> On 4 Nov 2008, at 15:08, Joseph Smarr wrote:
>> I think it should be <response><entry><displayName> and no >> <person> but the <entry> is of type person in XML-schema land. >> That would parallel the JSON and most closely follow the spec. >> Does that make sense?
>> Thanks, js
>> On Tue, Nov 4, 2008 at 1:29 AM, Ian Boston >> <ianbos...@googlemail.com> wrote:
>> I had previously posted an updated xsd for OS0.9, but having done >> some more implementation against the text of the 0.8.1 version of the >> spec I can see a conflict in the XSD between OS and PC.
>> 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>
>> 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>
>> 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.
> > >> From: opensocial-and-gadgets-spec@googlegroups.com
> > >> [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of
> > >> Scott Seely
> > >> Sent: Thursday, October 23, 2008 11:44 AM
> > >> To: opensocial-and-gadgets-spec@googlegroups.com
> > >> Subject: [opensocial-and-gadgets-spec] Resolve Schema with
> > >> Portable Contacts
> > >> 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.
> > > >> From: opensocial-and-gadgets-spec@googlegroups.com
> > > >> [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf
> Of
> > > >> Scott Seely
> > > >> Sent: Thursday, October 23, 2008 11:44 AM
> > > >> To: opensocial-and-gadgets-spec@googlegroups.com
> > > >> Subject: [opensocial-and-gadgets-spec] Resolve Schema with
> > > >> Portable Contacts
> > > >> 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.
|
