The issue with this format is that this is a new syntax for declaratively fetching OpenSocial data when we already have 2 others. The syntax we choose should be re-usable outside the context of templates e.g. proxied content fetching, non-template gadget data preloads and needs to makes sense in those contexts.
On Thu, Sep 25, 2008 at 11:29 AM, Scott Seely <[EMAIL PROTECTED]> wrote: > It looks like the OSML spec has the person/people stuff figured out. > For person/people, there is some information at > http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:PersonRequest.3E > . > > > > <os:PersonRequest key="Viewer" id="VIEWER" > fields="name,id,thumbnailUrl,books"/> > > > > <os:PeopleRequest key="PagedFriends" idSpec="VIEWER_FRIENDS" page="2" > pageSize="20"/> > > > > We wouldn't need a new syntax for Person, People, Activities, or AppData as > there is a different mapping independent of REST/XRDS. > > > > Does this solve the problem at hand? Is there a shortcoming in this > solution that I'm not seeing? > > > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > *On Behalf Of *Louis Ryan > *Sent:* Thursday, September 25, 2008 11:14 AM > > *To:* [EMAIL PROTECTED] > *Cc:* [EMAIL PROTECTED]; > [email protected] > *Subject:* Re: [os-templates] Declarative Data Definition - requirements > > > > I believe whats up for debate is what syntax to use. The 3 choices are very > roughly.... > > 1. Directly use the REST URL format > > <Preload id="friends" type="OS-REST" href=" > http://api.myspace.com/people/@self/@friends";> > > 2. Create some new format > > <os:DataRequest key="friend_data" service="people" > params="group=FRIENDS&sort=name"/> > > 3. Use the JSON-RPC format > > <Preload type="opensocial"> > [{ method : people.get, id : fiend_data, userId : "@self", groupId : > "@friends },...] > </Preload> > > My objection to 1. was because XRDS makes it by definition cross-container > incompatible. > My objection to 2 is because it's yet another syntax for specifying how to > fetch OpenSocial data. > > I'm certainly not arguing that 2. will not work with XRDS. > > On Thu, Sep 25, 2008 at 10:44 AM, Scott Seely <[EMAIL PROTECTED]> wrote: > > The prefetch/pipelining syntax doesn't even imply that the referenced > endpoints need to be stable across endpoints. The datapiplining syntax is > designed such that an implementation can do all the processing on the > server, all the processing on the client, or some combination of these. If > the specs break that in some way, that's bad—please point out where that is > true. If a client side implementation relies on REST for processing, the > container needs to do the following: > > 1. Request the XRDS document for the target. > > 2. Look for the service of the type of interest. > > 3. Post to the service using the os:URI-Template provided. > > > > This then allows one implementation to have a People that looks like this: > > <Service> > <Type>http://ns.opensocial.org/2008/opensocial/people</Type> > <os:URI-Template> > http://api.example.org/people/{guid}/{selector}/{pid}<http://api.example.org/people/%7Bguid%7D/%7Bselector%7D/%7Bpid%7D> > </os:URI-Template> > </Service> > > > > And another could have: > > > > <Service> > <Type>http://ns.opensocial.org/2008/opensocial/people</Type> > <os:URI-Template> > http://api.another-example.org/people?guid={guid}&selector={selector}&pid={pid}<http://api.another-example.org/people?guid=%7Bguid%7D&selector=%7Bselector%7D&pid=%7Bpid%7D> > </os:URI-Template> > </Service> > > > > We have to publish something in the container about how to contact the > container for more data. That could be a base URI (which is what a non-XRDS > solution would probably do) or an XRDS URI. The XRDS URI has a lot of extra > benefits that make it handy, whereas convention limits what we can publish. > > > > What am I missing? > > > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > *On Behalf Of *Louis Ryan > *Sent:* Thursday, September 25, 2008 10:26 AM > *To:* [EMAIL PROTECTED] > *Cc:* [EMAIL PROTECTED]; > [email protected] > *Subject:* Re: [os-templates] Declarative Data Definition - requirements > > > > I believe the issue with XRDS is that it works fine for programmatic > discovery of endpoints. The prefetch/pipelining syntax is declarative and > therefore if we choose the REST URL syntax it would require that the > referenced endpoints be stable and cross-container compatible. Im > don't know how close the URL structure of MySpaces REST APIs matches that in > Shindig for example but Im guessing there are some incompatibilities. > > > > As John mentioned and I alluded to on the other thread there was a proposal > to standardize on a URL format for REST that was cross-container compatible > without the need for XRDS. but it didn't see much traction. Would MySpace be > amenable to this? If not then we are left to choose between the RPC format > or something new. > > On Thu, Sep 25, 2008 at 8:06 AM, Scott Seely <[EMAIL PROTECTED]> wrote: > > I need to see an expansion on what is meant by "No full XRDS support." > MySpace has found XRDS to be very helpful. With XRDS, we get the following: > > · Flexibility in deployment. If/when we move endpoints, we only > need to leave the XRDS in place. > > · Discovery of extensions. We already use XRDS to advertise the > service types we offer for services that do not appear in OpenSocial. This > has been well-received by our existing customers. > > > > > > > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > *On Behalf Of *Evan Gilbert > *Sent:* Wednesday, September 24, 2008 11:36 PM > *To:* [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [email protected] > *Subject:* [os-templates] Declarative Data Definition - requirements > > > > Hi all - in order to reach consensus on declarative data definition, I > think it would help to first agree on requirements. > > Requirements (not all agreed to) from previous thread: > > - Support per-view specification of data requests > - Extensible for new data types > - Must be able to parametrize a data request (i.e., <os:PeopleRequest > ... page="${page}">) > - Must be possible to pass request data to client for processing > - Only one declarative syntax - we have to agree between templates and > preloads. > - 1:1 mapping of REST/RPC params to declarative syntax. No full XRDS > support > - Cannot require using <Content> > > > Some open questoins: > > - Do we need to parameterize data requests for preloads or only for > templates? > > > - Do we need to support: > <Preload> > <os:PeopleRequest ... page="${page}"> > </Preload> > > > - Is "Cannot require using <Content>" a requirement? > > > - The following would seem to be an option using <Content> > <Content type="proxied" href="http://yoursite.com";> > <os:DataRequest key="friend_data" service="people" > params="group=FRIENDS&sort=name"/> > </Content> > > Please send feedback on requirements - new ones, clarifications, or > questions about the requirements above. > > I think if we all agree on these requirements we'll be left with a much > simpler discussion on spec choices to implement. > > > > > > __._,_.___ Messages in this topic > <http://groups.yahoo.com/group/os-templates/message/151;_ylc=X3oDMTMzdm01M2VvBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNTgEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIyMzY3NDUwBHRwY0lkAzE1MQ-->( > 6) Reply (via web post) > <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwMmI0NHRxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNTgEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIyMzY3NDUw?act=reply&messageNum=158>| > Start > a new topic > <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmdXZoaXJmBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyMjIzNjc0NTA-> > > Messages<http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmNGIzZjJrBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyMjIzNjc0NTA->| > Files<http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJnajdlczliBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjIyMzY3NDUw>| > Photos<http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmZDFrM3E5BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyMjIzNjc0NTA->| > Links<http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJncGJrOHQ3BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjIyMzY3NDUw>| > Database<http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkNG43Y3ZwBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjIyMzY3NDUw>| > Polls<http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJnb2o0NGNvBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjIyMzY3NDUw>| > Members<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmc2ZxYzFhBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNtYnJzBHN0aW1lAzEyMjIzNjc0NTA->| > Calendar<http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJlZTJtb2lyBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNjYWwEc3RpbWUDMTIyMjM2NzQ1MA--> > [image: Yahoo! > Groups]<http://groups.yahoo.com/;_ylc=X3oDMTJlMHZrZTV2BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyMjM2NzQ1MA--> > Change settings via the > Web<http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJnbjRjZ3VxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNzdG5ncwRzdGltZQMxMjIyMzY3NDUw>(Yahoo! > ID required) > Change settings via email: Switch delivery to Daily Digest<[EMAIL > PROTECTED]:+Digest>| Switch > format to Traditional<[EMAIL PROTECTED]:+Traditional> > Visit Your Group > <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlOGEzcGFuBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNocGYEc3RpbWUDMTIyMjM2NzQ1MA-->| > Yahoo! > Groups Terms of Use <http://docs.yahoo.com/info/terms/> | Unsubscribe > <[EMAIL PROTECTED]> > Recent Activity > > - 6 > New > Members<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJndXIyMGtoBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMjIyMzY3NDUw> > > Visit Your Group > <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmMTJmM3BvBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEyMjIzNjc0NTA-> > New web site? > > Drive traffic > now.<http://us.ard.yahoo.com/SIG=13ook27k9/M=493064.12016308.12445700.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222374650/L=/B=EuYEN0LaX9g-/J=1222367450281610/A=3848642/R=0/SIG=131eshi2t/*http://searchmarketing.yahoo.com/arp/srchv2.php?o=US2004&cmp=Yahoo&ctv=Groups3&s=Y&s2=&s3=&b=50> > > Get your business > > on Yahoo! search. > Y! Messenger > > Instant > smiles<http://us.ard.yahoo.com/SIG=13ortc3ir/M=493064.12016274.12445679.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222374650/L=/B=E.YEN0LaX9g-/J=1222367450281610/A=3848577/R=0/SIG=12e714ic8/*http://us.rd.yahoo.com/evt=42403/*http://messenger.yahoo.com/feat_photos.php> > > Share photos while > > you IM friends. > Cat Groups > > on Yahoo! > Groups<http://us.ard.yahoo.com/SIG=13otmdgcd/M=493064.12016263.12445670.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222374650/L=/B=FOYEN0LaX9g-/J=1222367450281610/A=4836038/R=0/SIG=11olbte0b/*http://advision.webevents.yahoo.com/catzone/index.html> > > Share pictures & > > stories about cats. > . > > __,_._,___ >
