You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Evan Gilbert <ui...@google.com> on 2008/09/25 08:35:34 UTC
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.
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Declarative Data Definition - requirements
Posted by David Byttow <da...@google.com>.
On Thu, Sep 25, 2008 at 11:39 AM, Kevin Brown <et...@google.com> wrote:
>
> The problem with this solution is that it's a 6th mapping for social data
> (JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
>
> That's not really reasonable to expect developers to learn, especially
> since different sites are going to support different things. Many people are
> already frustrated at inconsistencies between implementations.
>
> I don't see that as an effective argument against defining XML markup to
wrap one or more of the other protocols (e.g. the javascript APIs on the
client). A developer does not need to learn all 6 to build an app as they
can build a fairly compelling app right now with just the javascript APIs.
This is just a layer of abstraction with side-benefits of performance and
simplicity.
One of the primary goals of this is to support on the client and/or server
seamlessly such that a developer can worry less about whether or not it will
work on a given container.
David
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Declarative Data Definition - requirements
Posted by Louis Ryan <lr...@google.com>.
I agree with all the requirements. I also feel strongly that we need 1:1 and
I think that should be achievable.
On Thu, Sep 25, 2008 at 12:04 PM, Evan Gilbert <ui...@google.com> wrote:
> I was hoping not to get down to this level of detail yet - we have 6 other
> requirements to discuss and this discussion keeps overwhelming all other
> threads.
>
> I feel pretty strongly that the only actual requirement is a 1:1 mapping to
> REST/RPC. We might decide to have this be the identity mapping, but that can
> be part of the "what's the best way to implement the requirements"
> discussion.
>
> Evan
>
>
> On 9/25/08, Kevin Brown <et...@google.com> wrote:
>>
>> On Thu, Sep 25, 2008 at 8:29 PM, Scott Seely <SS...@myspace.com> 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?
>>>
>>
>> The problem with this solution is that it's a 6th mapping for social data
>> (JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
>>
>> That's not really reasonable to expect developers to learn, especially
>> since different sites are going to support different things. Many people are
>> already frustrated at inconsistencies between implementations.
>>
>>
>>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Declarative Data
Definition - requirements
Posted by Evan Gilbert <ui...@google.com>.
Just to clarify, 1:1 mapping can mean any of the following things:
1. REST URL format (os:MakeRequest href="/people/@me")
2. Key/value params in URL format (os:MakeRequest
href="/people?person=@me"), very similar to 1
3. attribute/value pairs in XML element (os:PersonRequest person="@me')
4. JSON blob in XML (os:PersonRequest method="person" params="{person:
@me}">
etc...
I have strong opinions on which alternatives are better, but I think this is
a tangential discusison to the requirements.
On 9/25/08, Evan Gilbert <ui...@google.com> wrote:
>
> I was hoping not to get down to this level of detail yet - we have 6 other
> requirements to discuss and this discussion keeps overwhelming all other
> threads.
>
> I feel pretty strongly that the only actual requirement is a 1:1 mapping to
> REST/RPC. We might decide to have this be the identity mapping, but that can
> be part of the "what's the best way to implement the requirements"
> discussion.
>
> Evan
>
> On 9/25/08, Kevin Brown <et...@google.com> wrote:
>>
>> On Thu, Sep 25, 2008 at 8:29 PM, Scott Seely <SS...@myspace.com> 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?
>>>
>>
>> The problem with this solution is that it's a 6th mapping for social data
>> (JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
>>
>> That's not really reasonable to expect developers to learn, especially
>> since different sites are going to support different things. Many people are
>> already frustrated at inconsistencies between implementations.
>>
>> --~--~---------~--~----~------------~-------~--~----~
>> You received this message because you are subscribed to the Google Groups
>> "OpenSocial and Gadgets Specification Discussion" group.
>> To post to this group, send email to
>> opensocial-and-gadgets-spec@googlegroups.com
>> To unsubscribe from this group, send email to
>> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
>> For more options, visit this group at
>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
>> -~----------~----~----~----~------~----~------~--~---
>>
>>
>
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Declarative Data
Definition - requirements
Posted by Evan Gilbert <ui...@google.com>.
I was hoping not to get down to this level of detail yet - we have 6 other
requirements to discuss and this discussion keeps overwhelming all other
threads.
I feel pretty strongly that the only actual requirement is a 1:1 mapping to
REST/RPC. We might decide to have this be the identity mapping, but that can
be part of the "what's the best way to implement the requirements"
discussion.
Evan
On 9/25/08, Kevin Brown <et...@google.com> wrote:
>
> On Thu, Sep 25, 2008 at 8:29 PM, Scott Seely <SS...@myspace.com> 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?
>>
>
> The problem with this solution is that it's a 6th mapping for social data
> (JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
>
> That's not really reasonable to expect developers to learn, especially
> since different sites are going to support different things. Many people are
> already frustrated at inconsistencies between implementations.
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: [opensocial-and-gadgets-spec] RE: [os-templates] Declarative Data Definition - requirements
Posted by Kevin Brown <et...@google.com>.
On Thu, Sep 25, 2008 at 8:29 PM, Scott Seely <SS...@myspace.com> 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?
>
The problem with this solution is that it's a 6th mapping for social data
(JSON-RPC, XML-RPC, JSON-REST, ATOM-REST, javascript APIs, and now this).
That's not really reasonable to expect developers to learn, especially since
different sites are going to support different things. Many people are
already frustrated at inconsistencies between implementations.
Re: [os-templates] Declarative Data Definition - requirements
Posted by Louis Ryan <lr...@google.com>.
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 <ss...@myspace.com> 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:* os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
> *On Behalf Of *Louis Ryan
> *Sent:* Thursday, September 25, 2008 11:14 AM
>
> *To:* os-templates@yahoogroups.com
> *Cc:* opensocial-and-gadgets-spec@googlegroups.com;
> shindig-dev@incubator.apache.org
> *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 <ss...@myspace.com> 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:* os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
> *On Behalf Of *Louis Ryan
> *Sent:* Thursday, September 25, 2008 10:26 AM
> *To:* os-templates@yahoogroups.com
> *Cc:* opensocial-and-gadgets-spec@googlegroups.com;
> shindig-dev@incubator.apache.org
> *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 <ss...@myspace.com> 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:* os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
> *On Behalf Of *Evan Gilbert
> *Sent:* Wednesday, September 24, 2008 11:36 PM
> *To:* opensocial-and-gadgets-spec@googlegroups.com;
> os-templates@yahoogroups.com; shindig-dev@incubator.apache.org
> *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<os-templates-digest@yahoogroups.com?subject=Email+Delivery:+Digest>| Switch
> format to Traditional<os-templates-traditional@yahoogroups.com?subject=Change+Delivery+Format:+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
> <os-templates-unsubscribe@yahoogroups.com?subject=>
> 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.
> .
>
> __,_._,___
>
RE: [os-templates] Declarative Data Definition - requirements
Posted by Scott Seely <SS...@myspace.com>.
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: os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
On Behalf Of Louis Ryan
Sent: Thursday, September 25, 2008 11:14 AM
To: os-templates@yahoogroups.com
Cc: opensocial-and-gadgets-spec@googlegroups.com;
shindig-dev@incubator.apache.org
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 <ss...@myspace.com>
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}&selec
tor={selector}&pid={pid}
<http://api.another-example.org/people?guid=%7Bguid%7D&selector=%7Bselec
tor%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: os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
On Behalf Of Louis Ryan
Sent: Thursday, September 25, 2008 10:26 AM
To: os-templates@yahoogroups.com
Cc: opensocial-and-gadgets-spec@googlegroups.com;
shindig-dev@incubator.apache.org
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 <ss...@myspace.com> 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: os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
On Behalf Of Evan Gilbert
Sent: Wednesday, September 24, 2008 11:36 PM
To: opensocial-and-gadgets-spec@googlegroups.com;
os-templates@yahoogroups.com; shindig-dev@incubator.apache.org
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=X3oDMTMzcDh
mZTVkBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2d
JZAMxNTcEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIyMzY2NDgwBHRwY0lkAzE1MQ-->
(5) Reply (via web post)
<http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwMGhlaDJvBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNT
cEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIyMzY2NDgw?act=reply&messageNum=157>
| Start a new topic
<http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmY3NkdHZhBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH
NsawNudHBjBHN0aW1lAzEyMjIzNjY0ODA->
Messages
<http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmb251aD
dqBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNtc2dzBHN0aW1lAzEyMjIzNjY0ODA-> | Files
<http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJnaWJrcTZiB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNmaWxlcwRzdGltZQMxMjIyMzY2NDgw> | Photos
<http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmN2pyZXRk
BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRy
BHNsawNwaG90BHN0aW1lAzEyMjIzNjY0ODA-> | Links
<http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJnNjI5NmQ2B
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNsaW5rcwRzdGltZQMxMjIyMzY2NDgw> | Database
<http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkb29yNG
51BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNkYgRzdGltZQMxMjIyMzY2NDgw> | Polls
<http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJncXFnNGRjB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNwb2xscwRzdGltZQMxMjIyMzY2NDgw> | Members
<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmZGJxNGk
wBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnR
yBHNsawNtYnJzBHN0aW1lAzEyMjIzNjY0ODA-> | Calendar
<http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJldWFyMj
RuBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNjYWwEc3RpbWUDMTIyMjM2NjQ4MA-->
Yahoo! Groups
<http://groups.yahoo.com/;_ylc=X3oDMTJlNnBnbXExBF9TAzk3MzU5NzE0BGdycElkA
zIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyM
jM2NjQ4MA-->
Change settings via the Web
<http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJnNGE0Y2E3BF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH
NsawNzdG5ncwRzdGltZQMxMjIyMzY2NDgw> (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest
<mailto:os-templates-digest@yahoogroups.com?subject=Email%20Delivery:%20
Digest> | Switch format to Traditional
<mailto:os-templates-traditional@yahoogroups.com?subject=Change%20Delive
ry%20Format:%20Traditional>
Visit Your Group
<http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlZ3Bidm5hBF9TAzk
3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawN
ocGYEc3RpbWUDMTIyMjM2NjQ4MA--> | Yahoo! Groups Terms of Use
<http://docs.yahoo.com/info/terms/> | Unsubscribe
<mailto:os-templates-unsubscribe@yahoogroups.com?subject=>
Recent Activity
* 6
New Members
<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJnanVqcDB
jBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnR
sBHNsawN2bWJycwRzdGltZQMxMjIyMzY2NDgw>
Visit Your Group
<http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmaTRhczk2BF9TAzk
3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN
2Z2hwBHN0aW1lAzEyMjIzNjY0ODA->
Y! Messenger
Files to share?
<http://us.ard.yahoo.com/SIG=13og7ddha/M=493064.12016274.12445679.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222373680/L=/B=whkTJELaX9I-/J=12
22366480168119/A=3848578/R=0/SIG=11umg3fun/*http:/us.rd.yahoo.com/evt=42
403/*http:/messenger.yahoo.com>
Send up to 1GB of
files in an IM.
New web site?
Drive traffic now.
<http://us.ard.yahoo.com/SIG=13os9pqjj/M=493064.12016308.12445700.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222373680/L=/B=wxkTJELaX9I-/J=12
22366480168119/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! Groups blog
the best source
<http://us.ard.yahoo.com/SIG=13o0519og/M=493064.12016258.12582637.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222373680/L=/B=xBkTJELaX9I-/J=12
22366480168119/A=5191955/R=0/SIG=112mhte3e/*http:/www.ygroupsblog.com/bl
og/>
for the latest
scoop on Groups.
.
<http://geo.yahoo.com/serv?s=97359714/grpId=22548568/grpspId=1705375618/
msgId=157/stime=1222366480/nc1=3848578/nc2=3848642/nc3=5191955>
__,_._,___
Re: [os-templates] Declarative Data Definition - requirements
Posted by Louis Ryan <lr...@google.com>.
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 <ss...@myspace.com> 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:* os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
> *On Behalf Of *Louis Ryan
> *Sent:* Thursday, September 25, 2008 10:26 AM
> *To:* os-templates@yahoogroups.com
> *Cc:* opensocial-and-gadgets-spec@googlegroups.com;
> shindig-dev@incubator.apache.org
> *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 <ss...@myspace.com> 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:* os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
> *On Behalf Of *Evan Gilbert
> *Sent:* Wednesday, September 24, 2008 11:36 PM
> *To:* opensocial-and-gadgets-spec@googlegroups.com;
> os-templates@yahoogroups.com; shindig-dev@incubator.apache.org
> *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=X3oDMTMzcW5kZTRrBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNTUEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIyMzY0NzE1BHRwY0lkAzE1MQ-->(
> 4) Reply (via web post)
> <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwMWtrZzdmBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNTUEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIyMzY0NzE1?act=reply&messageNum=155>| Start
> a new topic
> <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmajRxdmZyBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyMjIzNjQ3MTU->
> Messages<http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmNHJjYWwwBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyMjIzNjQ3MTU->|
> Files<http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJnajBlaGZhBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjIyMzY0NzE1>|
> Photos<http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmbTMyYjFsBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyMjIzNjQ3MTU->|
> Links<http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJndW1qN3ZiBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjIyMzY0NzE1>|
> Database<http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkZm1sY2oxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjIyMzY0NzE1>|
> Polls<http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJnN290dTQ5BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjIyMzY0NzE1>|
> Members<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmOWFnNHIxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNtYnJzBHN0aW1lAzEyMjIzNjQ3MTU->|
> Calendar<http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJlcDRsYXRvBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNjYWwEc3RpbWUDMTIyMjM2NDcxNQ-->
> [image: Yahoo! Groups]<http://groups.yahoo.com/;_ylc=X3oDMTJlbTJsanJ0BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyMjM2NDcxNQ-->
> Change settings via the Web<http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJncWRxMjNwBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNzdG5ncwRzdGltZQMxMjIyMzY0NzE1>(Yahoo! ID required)
> Change settings via email: Switch delivery to Daily Digest<os-templates-digest@yahoogroups.com?subject=Email+Delivery:+Digest>| Switch
> format to Traditional<os-templates-traditional@yahoogroups.com?subject=Change+Delivery+Format:+Traditional>
> Visit Your Group
> <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlbDgza29wBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNocGYEc3RpbWUDMTIyMjM2NDcxNQ-->| Yahoo!
> Groups Terms of Use <http://docs.yahoo.com/info/terms/> | Unsubscribe
> <os-templates-unsubscribe@yahoogroups.com?subject=>
> Recent Activity
>
> - 6
> New Members<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJnNXI0bTNwBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMjIyMzY0NzE1>
>
> Visit Your Group
> <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmcnVkdWl1BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEyMjIzNjQ3MTU->
> Y! Messenger
>
> Quick file sharing<http://us.ard.yahoo.com/SIG=13o7sl6nt/M=493064.12016274.12445679.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222371915/L=/B=jdHwDULaX9E-/J=1222364715085670/A=3848580/R=0/SIG=11umg3fun/*http://us.rd.yahoo.com/evt=42403/*http://messenger.yahoo.com>
>
> Send up to 1GB of
>
> files in an IM.
> Need traffic?
>
> Drive customers<http://us.ard.yahoo.com/SIG=13ogso7bi/M=493064.12016308.12445700.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222371915/L=/B=jtHwDULaX9E-/J=1222364715085670/A=3848644/R=0/SIG=131l83flq/*http://searchmarketing.yahoo.com/arp/srchv2.php?o=US2006&cmp=Yahoo&ctv=Groups5&s=Y&s2=&s3=&b=50>
>
> With search ads
>
> on Yahoo!
> All-Bran
>
> 10 Day Challenge<http://us.ard.yahoo.com/SIG=13oi1tt7q/M=493064.12016283.12445687.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222371915/L=/B=j9HwDULaX9E-/J=1222364715085670/A=5202323/R=0/SIG=11aijbghb/*http://new.groups.yahoo.com/allbrangroup>
>
> Join the club and
>
> feel the benefits.
> .
>
> __,_._,___
>
RE: [os-templates] Declarative Data Definition - requirements
Posted by Scott Seely <SS...@myspace.com>.
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}</
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}&selec
tor={selector}&pid={pid}</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: os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
On Behalf Of Louis Ryan
Sent: Thursday, September 25, 2008 10:26 AM
To: os-templates@yahoogroups.com
Cc: opensocial-and-gadgets-spec@googlegroups.com;
shindig-dev@incubator.apache.org
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 <ss...@myspace.com> 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: os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
On Behalf Of Evan Gilbert
Sent: Wednesday, September 24, 2008 11:36 PM
To: opensocial-and-gadgets-spec@googlegroups.com;
os-templates@yahoogroups.com; shindig-dev@incubator.apache.org
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=X3oDMTMzdmR
lajVpBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2d
JZAMxNTQEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIyMzYzNTkzBHRwY0lkAzE1MQ-->
(3) Reply (via web post)
<http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwdTl0Z3QyBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNT
QEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIyMzYzNTkz?act=reply&messageNum=154>
| Start a new topic
<http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmdHA0ajRtBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH
NsawNudHBjBHN0aW1lAzEyMjIzNjM1OTM->
Messages
<http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmYmRrZz
BxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNtc2dzBHN0aW1lAzEyMjIzNjM1OTM-> | Files
<http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJnOXZwNDBzB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNmaWxlcwRzdGltZQMxMjIyMzYzNTkz> | Photos
<http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmMm90ZzRv
BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRy
BHNsawNwaG90BHN0aW1lAzEyMjIzNjM1OTM-> | Links
<http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJnamswNWQwB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNsaW5rcwRzdGltZQMxMjIyMzYzNTkz> | Database
<http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkdDhwcm
IxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNkYgRzdGltZQMxMjIyMzYzNTkz> | Polls
<http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJncTQzYmhlB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNwb2xscwRzdGltZQMxMjIyMzYzNTkz> | Members
<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmMjg2c2N
zBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnR
yBHNsawNtYnJzBHN0aW1lAzEyMjIzNjM1OTM-> | Calendar
<http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJlNW03cW
pvBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNjYWwEc3RpbWUDMTIyMjM2MzU5Mw-->
Yahoo! Groups
<http://groups.yahoo.com/;_ylc=X3oDMTJldDJxaGhhBF9TAzk3MzU5NzE0BGdycElkA
zIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyM
jM2MzU5Mw-->
Change settings via the Web
<http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJnNDRlcGhpBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH
NsawNzdG5ncwRzdGltZQMxMjIyMzYzNTkz> (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest
<mailto:os-templates-digest@yahoogroups.com?subject=Email%20Delivery:%20
Digest> | Switch format to Traditional
<mailto:os-templates-traditional@yahoogroups.com?subject=Change%20Delive
ry%20Format:%20Traditional>
Visit Your Group
<http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlNHY4N2N2BF9TAzk
3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawN
ocGYEc3RpbWUDMTIyMjM2MzU5Mw--> | Yahoo! Groups Terms of Use
<http://docs.yahoo.com/info/terms/> | Unsubscribe
<mailto:os-templates-unsubscribe@yahoogroups.com?subject=>
Recent Activity
* 6
New Members
<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJnbHRjNDU
yBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnR
sBHNsawN2bWJycwRzdGltZQMxMjIyMzYzNTkz>
Visit Your Group
<http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmN2l1aGlxBF9TAzk
3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN
2Z2hwBHN0aW1lAzEyMjIzNjM1OTM->
Y! Messenger
Group get-together
<http://us.ard.yahoo.com/SIG=13oh94lnq/M=493064.12016274.12445679.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222370793/L=/B=S06WOELaX.E-/J=12
22363593310254/A=3848584/R=0/SIG=12ceqob45/*http:/us.rd.yahoo.com/evt=42
403/*http:/messenger.yahoo.com/feat_conf.php>
Host a free online
conference on IM.
Y! Groups blog
The place to go
<http://us.ard.yahoo.com/SIG=13otnifoa/M=493064.12016258.12582637.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222370793/L=/B=TE6WOELaX.E-/J=12
22363593310254/A=5191953/R=0/SIG=112mhte3e/*http:/www.ygroupsblog.com/bl
og/>
to stay informed
on Groups news!
Yahoo! Groups
Join people over 40
<http://us.ard.yahoo.com/SIG=13o2mfihm/M=493064.12662708.12980600.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222370793/L=/B=TU6WOELaX.E-/J=12
22363593310254/A=5349276/R=0/SIG=11nhsqmjq/*http:/advision.webevents.yah
oo.com/EverydayWellness/>
who are finding ways
to stay in shape.
.
<http://geo.yahoo.com/serv?s=97359714/grpId=22548568/grpspId=1705375618/
msgId=154/stime=1222363593/nc1=3848584/nc2=5191953/nc3=5349276>
__,_._,___
Re: [opensocial-and-gadgets-spec] Re: [os-templates] Declarative Data Definition - requirements
Posted by Kevin Brown <et...@google.com>.
On Thu, Sep 25, 2008 at 11:16 PM, Scott Seely <SS...@myspace.com> wrote:
>
> The OSML audience is HTML coders, not JavaScript types. As a result, I
> have a hard time seeing the data request tags at
> http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#D
> ata_Request_Tags changing to match the REST URL syntax.
[bcc shindig-dev. This has nothing to do with this list.]
I strongly disagree. If you simply look at other platforms with similar
capabilities (i.e. normal web pages, or the facebook platform), most apps
are a mixture of markup and javascript. While I'm sure there are some people
who only know "some HTML", that's a very small percentage of the people who
are going to write OpenSocial apps. The current OSML draft proposal is very
complicated and will take time to learn -- I find it highly unlikely that
the people using it will be doing so because they're not "javascript types".
Nobody is saying that it *has to* match the REST URL syntax. We're trying to
lay out options and decide what makes the most sense.
> FWIW, our primary requirement is that a given OpenSocial REST endpoint
> MUST support XRDS. The structure of the endpoint URLs is an orthogonal
> discussion. If you like, feel free to kick off a separate thread on that
> item-- I can follow up and I think we can reach closure pretty simply.
>
> -----Original Message-----
> From: opensocial-and-gadgets-spec@googlegroups.com
> [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Louis
> Ryan
> Sent: Thursday, September 25, 2008 10:26 AM
> To: os-templates@yahoogroups.com
> Cc: opensocial-and-gadgets-spec@googlegroups.com;
> shindig-dev@incubator.apache.org
> Subject: [opensocial-and-gadgets-spec] 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.
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
RE: [opensocial-and-gadgets-spec] Re: [os-templates] Declarative Data Definition - requirements
Posted by Scott Seely <SS...@myspace.com>.
The OSML audience is HTML coders, not JavaScript types. As a result, I
have a hard time seeing the data request tags at
http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#D
ata_Request_Tags changing to match the REST URL syntax.
FWIW, our primary requirement is that a given OpenSocial REST endpoint
MUST support XRDS. The structure of the endpoint URLs is an orthogonal
discussion. If you like, feel free to kick off a separate thread on that
item-- I can follow up and I think we can reach closure pretty simply.
-----Original Message-----
From: opensocial-and-gadgets-spec@googlegroups.com
[mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Louis
Ryan
Sent: Thursday, September 25, 2008 10:26 AM
To: os-templates@yahoogroups.com
Cc: opensocial-and-gadgets-spec@googlegroups.com;
shindig-dev@incubator.apache.org
Subject: [opensocial-and-gadgets-spec] 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.
Re: [os-templates] Declarative Data Definition - requirements
Posted by Louis Ryan <lr...@google.com>.
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 <ss...@myspace.com> 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:* os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
> *On Behalf Of *Evan Gilbert
> *Sent:* Wednesday, September 24, 2008 11:36 PM
> *To:* opensocial-and-gadgets-spec@googlegroups.com;
> os-templates@yahoogroups.com; shindig-dev@incubator.apache.org
> *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=X3oDMTMzcTZpMHFzBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNTMEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIyMzU1MjE1BHRwY0lkAzE1MQ-->(
> 2) Reply (via web post)
> <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwYjl2Mmg3BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNTMEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIyMzU1MjE1?act=reply&messageNum=153>| Start
> a new topic
> <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmNGpjNmRyBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyMjIzNTUyMTU->
> Messages<http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmajYyZWlyBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyMjIzNTUyMTU->|
> Files<http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJnam81MTRxBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjIyMzU1MjE1>|
> Photos<http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmcGtuaTA1BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyMjIzNTUyMTU->|
> Links<http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJnaWR0ZWMyBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjIyMzU1MjE1>|
> Database<http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkMzByOTA3BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjIyMzU1MjE1>|
> Polls<http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJnYXAwbmlhBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjIyMzU1MjE1>|
> Members<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmcmVscXV2BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNtYnJzBHN0aW1lAzEyMjIzNTUyMTU->|
> Calendar<http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJlODY2cTJhBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNjYWwEc3RpbWUDMTIyMjM1NTIxNQ-->
> [image: Yahoo! Groups]<http://groups.yahoo.com/;_ylc=X3oDMTJlcXI1ZDh2BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyMjM1NTIxNQ-->
> Change settings via the Web<http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJnN2xqbGowBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNzdG5ncwRzdGltZQMxMjIyMzU1MjE1>(Yahoo! ID required)
> Change settings via email: Switch delivery to Daily Digest<os-templates-digest@yahoogroups.com?subject=Email+Delivery:+Digest>| Switch
> format to Traditional<os-templates-traditional@yahoogroups.com?subject=Change+Delivery+Format:+Traditional>
> Visit Your Group
> <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlZzVtdHRjBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNocGYEc3RpbWUDMTIyMjM1NTIxNQ-->| Yahoo!
> Groups Terms of Use <http://docs.yahoo.com/info/terms/> | Unsubscribe
> <os-templates-unsubscribe@yahoogroups.com?subject=>
> Recent Activity
>
> - 6
> New Members<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJnaHRsa2syBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMjIyMzU1MjE1>
>
> Visit Your Group
> <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmZG5vYXZyBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEyMjIzNTUyMTU->
> Y! Messenger
>
> Instant hello<http://us.ard.yahoo.com/SIG=13oss1mck/M=493064.12016274.12445679.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222362415/L=/B=mAdgOULaX98-/J=1222355215668797/A=3848581/R=0/SIG=11umg3fun/*http://us.rd.yahoo.com/evt=42403/*http://messenger.yahoo.com>
>
> Chat in real-time
>
> with your friends.
> Yahoo! Groups
>
> Balance your life<http://us.ard.yahoo.com/SIG=13onc4kof/M=493064.12016238.12823558.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222362415/L=/B=mQdgOULaX98-/J=1222355215668797/A=5286667/R=0/SIG=11in3uvr5/*http://new.groups.yahoo.com/planforabalancedlife>
>
> by learning how to
>
> make smart choices.
> Yahoo! Groups
>
> Join people over 40<http://us.ard.yahoo.com/SIG=13opg23mb/M=493064.12662708.12980600.8674578/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222362415/L=/B=mgdgOULaX98-/J=1222355215668797/A=5349276/R=0/SIG=11nhsqmjq/*http://advision.webevents.yahoo.com/EverydayWellness/>
>
> who are finding ways
>
> to stay in shape.
> .
>
> __,_._,___
>
RE: [os-templates] Declarative Data Definition - requirements
Posted by Scott Seely <SS...@myspace.com>.
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: os-templates@yahoogroups.com [mailto:os-templates@yahoogroups.com]
On Behalf Of Evan Gilbert
Sent: Wednesday, September 24, 2008 11:36 PM
To: opensocial-and-gadgets-spec@googlegroups.com;
os-templates@yahoogroups.com; shindig-dev@incubator.apache.org
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=X3oDMTMzZXE
2OGluBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2d
JZAMxNTEEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIyMzI0NTQyBHRwY0lkAzE1MQ-->
(1) Reply (via web post)
<http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwN3VyYWc3BF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxNT
EEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIyMzI0NTQy?act=reply&messageNum=151>
| Start a new topic
<http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmODFhcGtqBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH
NsawNudHBjBHN0aW1lAzEyMjIzMjQ1NDI->
Messages
<http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmOGE4c2
k4BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNtc2dzBHN0aW1lAzEyMjIzMjQ1NDI-> | Files
<http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJnb3N1amYwB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNmaWxlcwRzdGltZQMxMjIyMzI0NTQy> | Photos
<http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmMDhvOTdo
BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRy
BHNsawNwaG90BHN0aW1lAzEyMjIzMjQ1NDI-> | Links
<http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJnYmFqcWtoB
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNsaW5rcwRzdGltZQMxMjIyMzI0NTQy> | Database
<http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkdmE0dH
VwBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNkYgRzdGltZQMxMjIyMzI0NTQy> | Polls
<http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJnOHJ0cTc3B
F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB
HNsawNwb2xscwRzdGltZQMxMjIyMzI0NTQy> | Members
<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmbnRtcTQ
1BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnR
yBHNsawNtYnJzBHN0aW1lAzEyMjIzMjQ1NDI-> | Calendar
<http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJlcmhraT
Q3BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn
RyBHNsawNjYWwEc3RpbWUDMTIyMjMyNDU0Mg-->
Yahoo! Groups
<http://groups.yahoo.com/;_ylc=X3oDMTJlNWpzMWUzBF9TAzk3MzU5NzE0BGdycElkA
zIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyM
jMyNDU0Mg-->
Change settings via the Web
<http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJnczN2YmoxBF
9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH
NsawNzdG5ncwRzdGltZQMxMjIyMzI0NTQy> (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest
<mailto:os-templates-digest@yahoogroups.com?subject=Email%20Delivery:%20
Digest> | Switch format to Traditional
<mailto:os-templates-traditional@yahoogroups.com?subject=Change%20Delive
ry%20Format:%20Traditional>
Visit Your Group
<http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlOTF2ZGc3BF9TAzk
3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawN
ocGYEc3RpbWUDMTIyMjMyNDU0Mg--> | Yahoo! Groups Terms of Use
<http://docs.yahoo.com/info/terms/> | Unsubscribe
<mailto:os-templates-unsubscribe@yahoogroups.com?subject=>
Recent Activity
* 6
New Members
<http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJndm9pY3A
5BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnR
sBHNsawN2bWJycwRzdGltZQMxMjIyMzI0NTQy>
Visit Your Group
<http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmNnY2OWwyBF9TAzk
3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN
2Z2hwBHN0aW1lAzEyMjIzMjQ1NDI->
Need traffic?
Drive customers
<http://us.ard.yahoo.com/SIG=13opi04cp/M=493064.12016308.12445700.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222331742/L=/B=RktnMkLaX9A-/J=12
22324542156318/A=3848644/R=0/SIG=131l83flq/*http:/searchmarketing.yahoo.
com/arp/srchv2.php?o=US2006&cmp=Yahoo&ctv=Groups5&s=Y&s2=&s3=&b=50>
With search ads
on Yahoo!
Learn to live
a full life with these
<http://us.ard.yahoo.com/SIG=13ognv0eh/M=493064.12662709.12980595.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222331742/L=/B=R0tnMkLaX9A-/J=12
22324542156318/A=5349281/R=0/SIG=11ks6tatn/*http:/advision.webevents.yah
oo.com/HealthyLiving/>
healthy living
groups on Yahoo!
Y! Messenger
All together now
<http://us.ard.yahoo.com/SIG=13o7envt8/M=493064.12016274.12445679.867457
8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1222331742/L=/B=SEtnMkLaX9A-/J=12
22324542156318/A=3848585/R=0/SIG=12ceqob45/*http:/us.rd.yahoo.com/evt=42
403/*http:/messenger.yahoo.com/feat_conf.php>
Host a free online
conference on IM.
.
<http://geo.yahoo.com/serv?s=97359714/grpId=22548568/grpspId=1705375618/
msgId=151/stime=1222324542/nc1=3848644/nc2=5349281/nc3=3848585>
__,_._,___
Re: [opensocial-and-gadgets-spec] Declarative Data Definition - requirements
Posted by Kevin Brown <et...@google.com>.
On Thu, Sep 25, 2008 at 8:35 AM, Evan Gilbert <ui...@google.com> wrote:
> 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>
>
>
This is the same as not putting it in the content. The "cannot require using
Content" specifically meant "can not be in the CDATA section of the content
element". Doing this is no different from just including it in preloading.
>
> -
>
> 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.
>
>
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com<op...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>