Let's put this another way for the group.
We already know that being able to declaratively say what you want to do instead of doing so imperatively (markup vs. code) is a Good Thing. FaceBook has seen a lot of positive results from having a markup language paired with their API. What a few of us did was take a look at what FaceBook Markup Language does well, where it has shortcomings, and then applied that knowledge for the shared markup for OpenSocial. The result is the three part OSML proposal, currently in draft form at http://wiki.opensocial-templates.org/index.php?title=Main_Page. OSML has three parts: 1. OpenSocial Templating <http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Templat ing> :Open Social Template Part 1. A method for taking structured data (object graphs) and rendering UI elements in an arbitrary markup. A method for definining re-usable UI components that can be provided and extended by Containers and Developers. A set of standard elements that each Container implements. Client or server rendering depending on context. Dependency: None. 2. OpenSocial Markup <http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup> :Open Social Template Part 2. A set of standard tags and behaviors that utilize the above two technologies to provide the developer with a simple, declarative language for putting apps together. A developer can use it to create a simple, high performance application without a great deal of conceptual ramp-up. OSML weaves Data and Templating together for simplicity, but the developer can use the building blocks for more complexity if needed. 3. OpenSocial Data Pipelining <http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Data_Pi pelining> : Open Social Template Part 3. A method for grabbing OpenSocial and third-party data declaratively or in script and joining it to templates. A way to take results from data calls and send them back to the server (master-detail views). A method for paging and filtering large lists. Client or server side. Bootstraps the current DataRequest model for smooth compatibility and conceptual overlap. Dependency: OpenSocial Templating. This particular set of specs is different from FBML: they states not only what will be provided but they also set some expectations about how this functionality can be provided by containers. Finally, OSML is currently proposed with a unique gadget feature name. This means that a container that doesn't want to support OSML in all its glory does not have to in order to be 'OpenSocial'. Everything that the markup makes possible is also possible through JavaScript. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Byttow Sent: Friday, September 19, 2008 1:50 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [opensocial-and-gadgets-spec] Re: [os-templates] Re: [opensocial-and-gadgets-spec] Re: Declarative Data Definition Are you referring to using the JSON/RPC protocol for underpinning a declarative declaration or something else? I'm not sure that anyone has declared that we define a new protocol for OpenSocial. But we do want to create a declarative model for fetching data that can be piped into templates. It's just in our best interest to see where we can align those requirements with the requirements for preloading data. On Fri, Sep 19, 2008 at 12:33 PM, Robert Evans <[EMAIL PROTECTED]> wrote: +1 using existing JSON/RPC and not implementing Yet Another Protocol for OpenSocial. On Fri, Sep 19, 2008 at 9:58 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Fri, Sep 19, 2008 at 6:44 PM, Adam Winer <[EMAIL PROTECTED]> wrote: >> >> On Fri, Sep 19, 2008 at 9:22 AM, David Byttow <[EMAIL PROTECTED]> >> wrote: >> > The requirements for preloading data are probably a bit disjoint from >> > the >> > requirements for OS Templates, but as far as OSML interoperability goes: >> > >> > - Must be available to be processed on the client. >> >> What is the subject that goes with this sentence? The preloaded data, >> or the specification for that data request? I'm guessing the latter, >> based on the parameterization example below. >> >> > - Must be able to associate a string key with any given data request. >> >> +1, needed for all use cases. >> >> > - Must be able to parametrize a data request (i.e., <os:PeopleRequest >> > ... >> > page="${page}">) >> >> Preload/proxied probably wouldn't support parameterization, but that's >> a reasonable requirement for the syntax we choose. > > I don't understand what "parameterize a data request" means here. If we're > talking about parameters going to the social data server, that's a solid > argument for using the established server to server protocols, which can > already have arbitrary data passed to them. > >> >> >> > As I mentioned before, I think it is perfectly reasonable to move >> > forward >> > with a <Preload> or some other type of data-prefetching system that may >> > very >> > well partially underpin the data-pipelining system for OSML. There is no >> > requirement that says the systems must be one-in-the-same. >> >> No, but they should be as similar as possible and reasonable. >> >> -- Adam >> >> >> > >> > David >> > >> > On Fri, Sep 19, 2008 at 9:17 AM, Louis Ryan <[EMAIL PROTECTED]> wrote: >> >> >> >> I think using REST based preloads in this context is a bit of a >> >> non-starter because of the variety we allow in the URL structure and >> >> all >> >> that XRDS allows. We dont want gadget devs to have to create umpteen >> >> different gadget versions. >> >> >> >> If we agree that XRDS is a bad idea and that all URLs are structured >> >> the >> >> same way with some container specific offset then we could do something >> >> like >> >> this.. >> >> >> >> <Preload type="opensocial:rest" id="owner" href="/people/@owner..."> >> >> <Preload type="opensocial:rest" id="viewer" href="/people/@viewer..."> >> >> >> >> Note that the REST urls dont carry an id parameter with them explicitly >> >> as >> >> RPC does so we would need to allow an optional id attribute to allow >> >> retrieval from DataResponse objects. >> >> >> >> A new XML sytax while perhaps a little prettier I dont think will do >> >> anything to improve adoption so I'd rather avoid creating another >> >> format. >> >> >> >> So my votes would be >> >> >> >> +1 JSON-RPC >> >> +0 for REST that acts like XRDS doesnt exist OR a new syntax >> >> -100 for REST with XRDS >> >> >> >> >> >> >> >> >> >> On Thu, Sep 18, 2008 at 3:37 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: >> >>> >> >>> On Fri, Sep 19, 2008 at 12:14 AM, Adam Winer <[EMAIL PROTECTED]> wrote: >> >>>> >> >>>> On Thu, Sep 18, 2008 at 2:54 PM, Evan Gilbert <[EMAIL PROTECTED]> >> >>>> wrote: >> >>>> > The group working on OpenSocial templates is working on a proposal >> >>>> > for >> >>>> > how >> >>>> > to declaratively define the set of data passed into templates. >> >>>> > >> >>>> > In discussions, it looks like OpenSocial may need a declarative >> >>>> > syntax >> >>>> > in >> >>>> > other places: >> >>>> > >> >>>> > Data preloading >> >>>> > (possibly) to define what data gets sent to the 3rd party server >> >>>> > for >> >>>> > the >> >>>> > type="proxied" proposal >> >>>> > >> >>>> > Because this impacts other parts of the spec, we'd like to >> >>>> > encourage >> >>>> > people >> >>>> > interested in this topic to get involved in the design. There will >> >>>> > be >> >>>> > opportunity to give input at all phases of the process, and the >> >>>> > final >> >>>> > decision is always put up to a vote on the main spec list. However >> >>>> > we'd much >> >>>> > prefer to hear your feedback sooner. >> >>>> > >> >>>> > An example of the kind of syntax we're looking at: >> >>>> > >> >>>> > Replacing >> >>>> > >> >>>> > req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.OWNER), >> >>>> > "get_owner"); >> >>>> > With <os:PersonRequest key="get_owner" id="OWNER"> >> >>>> > >> >>>> > and links: >> >>>> > >> >>>> > Template discusison >> >>>> > group: http://tech.groups.yahoo.com/group/os-templates/ >> >>>> > In progress proposal for pipelining: >> >>>> >> >>>> > > >> >>>> > > http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Data_Pip elining >> >>>> >> >>>> Procedural question: where should we be discussing this? If it >> >>>> impacts the spec as a whole, I think it belongs on the spec group, >> >>>> not >> >>>> the os-templates working group. I'd think in the end, nothing's in >> >>>> the OpenSocial spec if it hasn't been discussed in its final form on >> >>>> the main list. >> >>> >> >>> Nothing goes into OpenSocial without being ratified on this list. It >> >>> says >> >>> so right here: http://docs.google.com/View?docid=dg3q7jr6_17hs5pbzdg >> >>> This goes for templates as a whole (the final version will have to be >> >>> voted on just like every other addition to the specification). >> >>> Duplicate syntax is bad for everyone, and I for one am completely >> >>> against >> >>> it. It's bad enough that we already have to support the javascript >> >>> wrapper >> >>> objects in addition to 4 or 5 variants of the social data APIs, lets >> >>> please >> >>> not make it more complicated (and even less portable) than it already >> >>> is. >> >>> >> >>>> >> >>>> > >> >>>> > So... please get involved if you have ideas about how data requests >> >>>> > should >> >>>> > be defined. >> >>>> >> >>>> Procedure aside: I'm generally a big fan of strongly-defined syntax, >> >>>> e.g.: >> >>>> <os:PersonRequest key="get_owner" id="OWNER"> >> >>>> vs. something like: >> >>>> {method:"person.get", id:"get_owner, id_spec="OWNER"} >> >>>> >> >>>> The former is much easier to syntactically validate, support with >> >>>> tools, >> >>>> etc. >> >>>> >> >>>> On the other hand: the latter is much more extensible - is there a >> >>>> plan to support third-party data extensions beyond "custom request >> >>>> handlers", which appear specific to client-side processing? >> >>> >> >>> We've been bitten too many times with inflexible data structures like >> >>> that. The latter is really the only viable option. >> >>> The requests themselves can easily take the form of *any* social data >> >>> call...see more below. >> >>>> >> >>>> The other critical question is *where* these go when used outside of >> >>>> OpenSocial templates: <Features>, or <Content>? I'd mostly like to >> >>>> leave that question to the experts on gadget parsing and rendering, >> >>>> but I think it's been pointed out already that <Content> doesn't >> >>>> exist >> >>>> for type="proxied". >> >>> >> >>> We already have HTTP preloads, and social data easily maps to HTTP >> >>> requests (because of the data APIs). We could probably augment the >> >>> existing >> >>> Preload element for this. >> >>> For instance, a REST request might look like this: >> >>> <Preload href="<restful path only, not host/port/protocol>" >> >>> type="rest"/> >> >>> Bodies can just be included in the CDATA: >> >>> <Preload type="rpc"><![CDATA[{method:"person.get", id:"get_owner, >> >>> id_spec="OWNER"}]]></Preload> >> >>> Instead of having to define entirely new, arbitrary constructs >> >>> (again), >> >>> we can reuse what we already have. >> >>> - For templates, the data is available and populated as properties to >> >>> be >> >>> used in the expressions. >> >>> - For gadget preloading (non-proxied), the data can be passed down to >> >>> the >> >>> client in a transparent way and mapped to the original request so that >> >>> it >> >>> works seamlessly with existing opensocial calls. This is the same way >> >>> that >> >>> HTTP preloading is done. >> >>> - For gadget preloading (proxied), the data can be pushed across as >> >>> POST >> >>> to the remote site. >> >>> Putting this into the Content section REQUIRES that it is duplicated >> >>> elsewhere to support everything else, because supporting proxied >> >>> content >> >>> requires it. >> >>> >> >>>> >> >>>> -- Adam >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en -~----------~----~----~----~------~----~------~--~--- __._,_.___ Messages in this topic <http://groups.yahoo.com/group/os-templates/message/124;_ylc=X3oDMTMzY2F 1aWg1BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2d JZAMxMzAEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjIxODU3Mzk1BHRwY0lkAzEyNA--> (4) Reply (via web post) <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJwcmNqcXFuBF 9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARtc2dJZAMxMz AEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjIxODU3Mzk1?act=reply&messageNum=130> | Start a new topic <http://groups.yahoo.com/group/os-templates/post;_ylc=X3oDMTJmZXRqcWRxBF 9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH NsawNudHBjBHN0aW1lAzEyMjE4NTczOTU-> Messages <http://groups.yahoo.com/group/os-templates/messages;_ylc=X3oDMTJmYnVlNn BlBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn RyBHNsawNtc2dzBHN0aW1lAzEyMjE4NTczOTU-> | Files <http://groups.yahoo.com/group/os-templates/files;_ylc=X3oDMTJncG91cTJyB F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB HNsawNmaWxlcwRzdGltZQMxMjIxODU3Mzk1> | Photos <http://groups.yahoo.com/group/os-templates/photos;_ylc=X3oDMTJmajl1ZjJm BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRy BHNsawNwaG90BHN0aW1lAzEyMjE4NTczOTU-> | Links <http://groups.yahoo.com/group/os-templates/links;_ylc=X3oDMTJnNjFpaWUzB F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB HNsawNsaW5rcwRzdGltZQMxMjIxODU3Mzk1> | Database <http://groups.yahoo.com/group/os-templates/database;_ylc=X3oDMTJkYzZiZG 41BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn RyBHNsawNkYgRzdGltZQMxMjIxODU3Mzk1> | Polls <http://groups.yahoo.com/group/os-templates/polls;_ylc=X3oDMTJnaWsydHRlB F9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyB HNsawNwb2xscwRzdGltZQMxMjIxODU3Mzk1> | Members <http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJmZmE1ZXJ rBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnR yBHNsawNtYnJzBHN0aW1lAzEyMjE4NTczOTU-> | Calendar <http://groups.yahoo.com/group/os-templates/calendar;_ylc=X3oDMTJlM3RvMm k0BF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZn RyBHNsawNjYWwEc3RpbWUDMTIyMTg1NzM5NQ--> Yahoo! Groups <http://groups.yahoo.com/;_ylc=X3oDMTJlcDB2MTEyBF9TAzk3MzU5NzE0BGdycElkA zIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTIyM Tg1NzM5NQ--> Change settings via the Web <http://groups.yahoo.com/group/os-templates/join;_ylc=X3oDMTJnanB0OG0wBF 9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBH NsawNzdG5ncwRzdGltZQMxMjIxODU3Mzk1> (Yahoo! ID required) Change settings via email: Switch delivery to Daily Digest <mailto:[EMAIL PROTECTED]:%20 Digest> | Switch format to Traditional <mailto:[EMAIL PROTECTED] ry%20Format:%20Traditional> Visit Your Group <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJlaHNncGo3BF9TAzk 3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDZnRyBHNsawN ocGYEc3RpbWUDMTIyMTg1NzM5NQ--> | Yahoo! Groups Terms of Use <http://docs.yahoo.com/info/terms/> | Unsubscribe <mailto:[EMAIL PROTECTED]> Recent Activity * 6 New Members <http://groups.yahoo.com/group/os-templates/members;_ylc=X3oDMTJnMDE5ZHR pBF9TAzk3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnR sBHNsawN2bWJycwRzdGltZQMxMjIxODU3Mzk1> Visit Your Group <http://groups.yahoo.com/group/os-templates;_ylc=X3oDMTJmams0bTlmBF9TAzk 3MzU5NzE0BGdycElkAzIyNTQ4NTY4BGdycHNwSWQDMTcwNTM3NTYxOARzZWMDdnRsBHNsawN 2Z2hwBHN0aW1lAzEyMjE4NTczOTU-> Women of Curves on Yahoo! Groups <http://us.ard.yahoo.com/SIG=14kjj7bjs/M=493064.12016299.12445691.113227 65/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221864595/L=/B=yPCYBkLaX.8-/J=1 221857395977115/K=n4PWll7gLtzWdqF.1OO3vg--/A=4990213/R=0/SIG=11odsb6gn/* http:/new.groups.yahoo.com/Women_Of_Curves_Everywhere> A positive group to discuss Curves. Weight Loss Group on Yahoo! Groups <http://us.ard.yahoo.com/SIG=14kobhold/M=493064.12016300.12445692.113231 96/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221864595/L=/B=yfCYBkLaX.8-/J=1 221857395977115/K=n4PWll7gLtzWdqF.1OO3vg--/A=5170419/R=0/SIG=11b5gu1oe/* http:/new.groups.yahoo.com/specialKgroup> Get support and make friends online. Yahoo! Groups Familyographer Zone <http://us.ard.yahoo.com/SIG=14jedh1mj/M=493064.12717544.13024012.867457 8/D=groups/S=1705375618:NC/Y=YAHOO/EXP=1221864595/L=/B=yvCYBkLaX.8-/J=12 21857395977115/K=n4PWll7gLtzWdqF.1OO3vg--/A=5370579/R=0/SIG=11lnr7bf1/*h ttp:/advision.webevents.yahoo.com/familyographer/> Learn how to capture family moments. . <http://geo.yahoo.com/serv?s=97359714/grpId=22548568/grpspId=1705375618/ msgId=130/stime=1221857395/nc1=4990213/nc2=5170419/nc3=5370579> __,_._,___
