Fixes to the OSML spec

- Removed <os:Get>.
- Added reasoning for its removal w/ suggested workaround
- Added note on <script> tags 
- Added <script> tags to examples
- Made Proxied render use case more detailed

[awiner, 2009-03-27 00:26:17]

http://codereview.appspot.com/32044/diff/1/2
File draft/OpenSocial-Markup-Language-Tags.xml (left):

http://codereview.appspot.com/32044/diff/1/2#oldcode61
Line 61: Inline tag to show a person's name, linked if the a profile URL an may
have additional container bling (i.e. more information on hover)
need some grammar fixes in this line.

http://codereview.appspot.com/32044/diff/1/2
File draft/OpenSocial-Markup-Language-Tags.xml (right):

http://codereview.appspot.com/32044/diff/1/2#newcode83
Line 83: <t>@person {string|Object} The person object or DataContext key
referring to a
Think this should always be a Person object.
Supporting a DataContext key just saves you the ${} braces.

http://codereview.appspot.com/32044/diff/1/2#newcode89
Line 89: Welcome, &lt;script type="text/os-template"
xmlns:os="http://ns.opensocial.org/2008/markup"&gt;&lt;os:Name
person="${Viewer}"/&gt;&lt;/script&gt;
would probably put the script around the whole thing (don't want people thinking
we're *totally* crazy with that script element)

http://codereview.appspot.com/32044/diff/1/2#newcode101
Line 101: <t>@group {string|Object} An array of person objects or DataContext
key referring to an array
ditto

http://codereview.appspot.com/32044/diff/1/2#newcode109
Line 109: <t>@onselect {string|function} Client side script function to invoke
when a person
what can the script do?  what arguments does it take?  When is it called for
multiple selection?  We might punt this out of the spec and make it a container
extension, or we can try fully specifying it.

http://codereview.appspot.com/32044/diff/1/2#newcode218
Line 218: <t>Then use ${Data} in your template.</t>
need <os:Html code="${Data}"/> if the request includes any markup.

[Evan Gilbert (code review), 2009-03-27 00:54:35]

http://codereview.appspot.com/32044/diff/1/2
File draft/OpenSocial-Markup-Language-Tags.xml (right):

http://codereview.appspot.com/32044/diff/1/2#newcode83
Line 83: <t>@person {string|Object} The person object or DataContext key
referring to a
On 2009/03/27 00:26:17, awiner wrote:
> Think this should always be a Person object.
> Supporting a DataContext key just saves you the ${} braces.

Agree with Adam on this.

http://codereview.appspot.com/32044/diff/1/2#newcode109
Line 109: <t>@onselect {string|function} Client side script function to invoke
when a person
On 2009/03/27 00:26:17, awiner wrote:
> what can the script do?  what arguments does it take?  When is it called for
> multiple selection?  We might punt this out of the spec and make it a
container
> extension, or we can try fully specifying it.

Think the callback should be either:
1. callback(idsOfPeople) or
2. callback(listOfPeopleObjects)

#1 probably makes sense given server side rendering - you don't want to have to
keep the people around. But #2 would make it easier to do something with the
selected people without looking them up.

http://codereview.appspot.com/32044/diff/1/2#newcode218
Line 218: <t>Then use ${Data} in your template.</t>
On 2009/03/27 00:26:17, awiner wrote:
> need <os:Html code="${Data}"/> if the request includes any markup.

There was a long discussion which ended in having <os:Get>, and I only want to
reverse the decision and remove the tag if we have agreement from all folks who
wanted the the functionality (MySpace/Yahoo folks - please review this)

<os:Get> supports repeated and conditional download of data, so we lose some
functionality in the other constructs.

Think it's OK for the client side implementation and/or Shindig server-side
implementation to be naive and slow (deferred load via JS) - if developers like
the feature we can then improve performance.