Hi everyone - wanted to send an update on OSML. We've been making good progress on the spec. The template discussion group has a initial set of tags and design for data pipelining that we hope to propose to the community at large soon. Notes from a meeting we had earlier this week below.
If you're interested in contributing to the spec proposal, please join the OSML discussion group @ http://tech.groups.yahoo.com/group/os-templates/. Thanks, Evan ---------- Forwarded message ---------- From: Evan Gilbert <[EMAIL PROTECTED]> Date: Thu, Aug 14, 2008 at 7:17 AM Subject: Notes from OSML deep dive @ Yahoo To: [EMAIL PROTECTED] As I mentioned before, a number of us met at Yahoo earlier this week to try to accelerate consensus on the initial set of OSML tags. We came to internal consensus on a number of details, and want to propose these resolutions back to the community. *Attendees* Charlie Jiang, Isaac Schlueter, Xavier Legros, John Hardy, Chris Bissel, Max Newbould, Scott Seely, Mike Austin, David Byttow, Evan Gilbert *Goals* Agreement on the following goals: - Aim for a unified model between type="proxied" and type="html". Also have this model support content pushed via a setView() call or equivalent in the future - Syntax / overhead should be as minimal as possible for developers - We should aim to support the range of. For example, <os:PersonSelector group="somegroup"> seemed more appropriate than <os:FriendSelector person="(VIEWER || OWNER)"> *OSML and Data Pipelining* Would like to use OpenSocial Data Pipelining ( http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Data_Pipelining) as the standard way for OSML tags to access OpenSocial data. - Data can be loaded explicitly via <os:DataSet> and then referenced by OSML tags. Example: <os:DataSet key="PagedFriends"> <os:PeopleRequest group="OWNER_FRIENDS" pageNumber="1" pageSize="40"/> </os:DataSet> ... <os:PeopleSelector group="${PagedFriends}" name="formFieldName"> - We will work as much as possible to minimize syntax overhead - For data requests that need parameters, we will look at simplified syntax options. Simplified version of the above data request: <os:PeopleRequest *key="PagedFriends" *group="OWNER_FRIENDS" pageNumber="1" pageSize="40"/> - For data requests that don't need parameters or have good defaults, we will implicitly define them. For example: <os:PersonRequest key="OpenSocialViewer" fields="name,id,thumbnailUrl,profileUrl"/> would probaby be implied and you can always call the following without explicitly making a data request <os:Badge person="${OpenSocialViewer}"> and ${OpenSocialViewer.Name} - The advantages of this approach: - Supports accessing full set of OpenSocial API data - Adapts to different use cases easily - <os:PeopleSelector group="${SomeGroup}"> supports many more use cases than <os:FriendSelector person="VIEWER">. - Relatively minimal developer overhead: - For calls to OpenSocial APIs that need parameters, the developer will need to add ~1 line of code - Calls that don't need parameters are for free - Provides a consistent model across all OpenSocial content types - Data binding supports many common developer needs that tags alone can't - Supports data in attributes and JavaScript, i.e.: <a title="This will alert for ${Viewer.Name}" href="#" onclick="alert('Hello ${Viewer.Name}')"> - Supports internationalization more cleanly: - <os:pronoun> doesn't work for all countries - Variants of the following will: <div if="${Person.Gender == 'MALE'}">He said</div><div if="${Person.Gender='FEMALE'}">She said</div> - All fields on OpenSocial person object *Tags* Agreed on the following tags... Wiki hasn't been updated yet, so deltas are called out below - <os:Name><http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:name.3E> - Inline tag to show a person's name, possibly linked and/or with inline container bling (i.e. more information on hover) - @person parameter will be an object - Discussion over whether we needed this tag - ${Person.Name} could be sufficient. We felt that linking and container bling made this worthy of a separate tag - <os:Badge><http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:badge.3E>- Block level tag to show information about a person in the style of the container, usually with a photo - @person parameter will be an object - Discussion that we could allow for a size parameter (small|medium|large). We felt that we could add this later when we have more concrete use cases - <os:PeopleSelector><http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:friendSelector.3E> - Tag to show a UI that chooses from a list of people, and sets a form field with the associated value - Name was changed to PeopleSelector from FriendSelector to accurately represent that it can be any group of people - @person will be changed to @group, which references the group of people from which you are selecting - Discussion that we could support @onchange parameter for taking actions immediately when user selects someone (similar to HTML onchange). We agreed this might be useful but not required and we can easily add it easily in the future. - <os:TabSet>/<os:Tab><http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Markup#.3Cos:tabset.3E>tags to create a tabbed UI - No changes from Wiki spec. - The examples show an @src parameter for having a tab load data from an OpenSocial view or possibly navigate to a view when clicked. We discussed this and felt that it wasn't required for the initial spec. *Syntax* - People were generally flexible but the group had a preference for <os:UpperCamelCase>. It seemed easier to read and type.
