Proposal for 1.0 - Clarify template parameter behavior

[goosemanjack]

Synopsis:

The OpenSocial template spec does not clearly define how to handle
called template instances where the same parameter is used multiple
times or namespaced parameters are used. Proposal is to add language
stating that only one value is allowed for a given parameter and
define behavior where namespaces are used.


In the OpenSocial Templating Specification, parameters passed to
custom tag instances are defined with the following statement:

"Parameters can be passed into templates as XML attributes or
elements. These parameters are accessed using the special variable $
{My}:"

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.8.4

We would like to add additional clarifying text:

1. Parameters may only contain one value under a given name. If the
same name appears multiple times as an element parameter within a
given custom tag instance, only the final parameter value will be
used. This is the same behavior as repeatedly assigning values to a
single variable.

2. When the same parameter name appears as both an element and an
attribute, the attribute-defined parameter will take final precedence.

3. A namespaced parameter where the namespace matches the namespace of
the defined tag will have the parameter value placed in the ${My}
variable under the local name.

ex:
<script type="text/os-template" tag="myapp:HelloWorld">
Hello, ${My.title}
</script>
...
<myapp:HelloWorld>
<myapp:title>I am the title</myapp:title>
</myapp:HelloWorld>

will have the local value ${My.title} defined as "I am the title".

4. A namespaced parameter where the namespace does not match the
namespace of the defined tag will be discarded and not registered with
the ${My} variable.

5. A namespaced parameter where the local name matches a non-
namespaced parameter will be treated as a repeated instance of that
parameter.

ex:

<myapp:HelloWorld>
<title>Foo</title>
<myapp:title>Namespaced title</myapp:title>
</myapp:HelloWorld>

will have the local value ${My.title} defined as "Namespaced title".

[Lev Epshteyn]

I'm against (1), since it prevents passing in repeatable input. As I mentioned in another thread, there are use cases where you want to get child elements of a certain type as a list to iterate over.

The other points seem generally reasonable. I don't see why you'd want to be able to access as ${My.foo} the value of "foo" tag in a different namespace. The only caveat is that this can be useful for <os:Render> (at least inasmuch as not dropping tags from a different NS when rendering entire content)

[Jorge Reyes]

I'm with Chris in point 1 

<myApp:ColorTag color="green">

<myApp:Color>red</myApp:Color>

<myApp:Color>blue</myApp:Color>

</myApp:ColorTag>

This should evaluate to green.

<myApp:ColorTag>

<myApp:Color>red</myApp:Color>

<myApp:Color>blue</myApp:Color>

</myApp:ColorTag>

This should evaluate to blue.

This is the problem that I see if we try to convert to an array if there is more than one element

<myApp:ColorTag>

<myApp:Color>red</myApp:Color>

</myApp:ColorTag>

we will end with My.Color and this will return red

then 

<myApp:ColorTag Color="green">

<myApp:Color>red</myApp:Color>

<myApp:Color>blue</myApp:Color>

</myApp:ColorTag>

we will have My.Color = ["green","red", "blue"]

if I'm expecting and array and I just have one element how do can I specify and array of one element.

I'm also for consistency. Either we add name space to all the child element or we don't

I'm happy to go 

<myApp:ColorTag>

<myApp:Color>blue</myApp:Color>

</myApp:ColorTag>

or

<myApp:ColorTag>

<Color>blue</Color>

</myApp:ColorTag>

but not both this can be a source of confusion. 

[Lev Epshteyn]

On Thu, Oct 8, 2009 at 3:28 PM, Jorge Reyes <jer...@gmail.com> wrote:

I'm with Chris in point 1 

<myApp:ColorTag color="green">

<myApp:Color>red</myApp:Color>

<myApp:Color>blue</myApp:Color>

</myApp:ColorTag>

This should evaluate to green.

Agreed - but it will evaluate to "green" because of point 2 (attribute takes precedence over child elements), not point 1.
 

<myApp:ColorTag>

<myApp:Color>red</myApp:Color>

<myApp:Color>blue</myApp:Color>

</myApp:ColorTag>

This should evaluate to blue.

This is the problem that I see if we try to convert to an array if there is more than one element

<myApp:ColorTag>

<myApp:Color>red</myApp:Color>

</myApp:ColorTag>

we will end with My.Color and this will return red

then 

<myApp:ColorTag Color="green">

<myApp:Color>red</myApp:Color>

<myApp:Color>blue</myApp:Color>

</myApp:ColorTag>

we will have My.Color = ["green","red", "blue"]

I don't think anyone is arguing about merging attributes and child elements into a single array.

However, without the ability to get a list of child nodes, there is no way to iterate over them. Are you arguing for dropping support such iteration? If not, please specify an alternative mechanism to support them.

Specifically, today, we can build custom tags like this:

<my:Recipe name="Omelet">
  <my:Ingredient>Cup of milk</my:Ingredient>
  <my:Ingredient>3 eggs</my:Ingredient>
  <my:Ingredient>2 Slices of Cheese</my:Ingredient>
  <my:Step>Beat the eggs and milk together until consistent</my:Step>
  <my:Step>Put into a well-oiled frying pan on medium flame</my:Step>
  <my:Step>Add Cheese slices on top</my:Step>
</my:Recipe>

The tag definition can first render all the ingredients in order, then all the steps in order using a combination of ${My} and <os:Render>.

[goosemanjack]

> I'm against (1), since it prevents passing in repeatable input.

Number 1 does not prevent repeatable input. If an app wants to
register repeatable input, it can be done thru the javascript API as
follows:

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Data-Pipelining.html#rfc.section.11

EX:
var someData = [];
someData.push("red");
someData.push("blue");
someData.push("green");

opensocial.data.DataContext.putDataSet("newfoo", someData)
...

<myapp:ColorTest>
<color>${newfoo}</color>
</myapp:ColorTest>


A custom tag instance parameter is analogous to a variable
declaration. In every language I've ever come across values of a
variable are overwritten in subsequent assignments. I've never seen
an implementation where assigning multiple times to a variable
converts it from a scalar value to an array. Also, I simply can't see
a use case for using multiple-assignment to generate arrays when it is
possible to construct arrays of data by using actual arrays and the
Javascript API.
--
clc

On Oct 8, 7:55 am, Lev Epshteyn <le...@google.com> wrote:
> I'm against (1), since it prevents passing in repeatable input. As I
> mentioned in another thread, there are use cases where you want to get child
> elements of a certain type as a list to iterate over.
>
> The other points seem generally reasonable. I don't see why you'd want to be
> able to access as ${My.foo} the value of "foo" tag in a different namespace.
> The only caveat is that this can be useful for <os:Render> (at least
> inasmuch as not dropping tags from a different NS when rendering entire
> content)
>
> On Thu, Oct 8, 2009 at 10:42 AM, goosemanjack <cc...@myspace.com> wrote:
>
> > Synopsis:
>
> > The OpenSocial template spec does not clearly define how to handle
> > called template instances where the same parameter is used multiple
> > times or namespaced parameters are used.  Proposal is to add language
> > stating that only one value is allowed for a given parameter and
> > define behavior where namespaces are used.
>
> > In the OpenSocial Templating Specification, parameters passed to
> > custom tag instances are defined with the following statement:
>
> > "Parameters can be passed into templates as XML attributes or
> > elements. These parameters are accessed using the special variable $
> > {My}:"
>

> >http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

[goosemanjack]

> I've never seen
> an implementation where assigning multiple times to a variable
> converts it from a scalar value to an array.

The above statement should read:

"I've never seen an implementation where assigning multiple times to a

variable converts it from a single value variable to an array."

On Oct 8, 3:27 pm, goosemanjack <cc...@myspace.com> wrote:
> > I'm against (1), since it prevents passing in repeatable input.
>

> Number 1 does not prevent repeatable input.  If an app wants to
> register repeatable input, it can be done thru the javascript API as
> follows:
>

> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

[Adam Winer]

On Thu, Oct 8, 2009 at 3:27 PM, goosemanjack <cc...@myspace.com> wrote:
>
>> I'm against (1), since it prevents passing in repeatable input.
>

> Number 1 does not prevent repeatable input.  If an app wants to
> register repeatable input, it can be done thru the javascript API as
> follows:

-1. I'm not OK with making parts of OST javascript-specific unless
absolutely necessary. Shindig supports fully server-side execution,
and at least one large container requires that for some views.

I find the current XML syntax reasonable.

[Lev Epshteyn]

Wait, Chris, are you saying that for markup like

<my:Colors>
   <color>Red</color>
   <color>Green</color>
   <color>Blue</color>
</my:Colors>

you find color="Blue" a more reasonable representation than color=["Red", Green", "Blue"] ?

This seems to fly in the face of XML convention where multiple child tags with the same name are generally allowed and result in list-like structure. I agree there are some situations where this can lead to confusion, but these are generally error edge cases.

I'm very much against (1) because it defies reasonable expectation of what a particular piece of markup does, and because it makes passing in list parameters impossible by declarative markup alone.

[goosemanjack]

I would contend that we're using XML notation to assign values in a
programming language (the EL). We're not using DOM traversal or
XPath.

The ability to define an array in the parameters does seem like a
useful feature, so let's try to come up with a notation that is more
obvious as to intent and we can all agree on. As an initial pass,
consider this as item #6 in the proposal to clarify the behavior of
parameters within custom tag template instances:

#6 Arrays in parameters:

Parameter keys containing arrays of values may be created with an
<Array> element as a direct element child of the custom tag instance.
The key is defined with the @key attribute. Items of the array are
defined with the <Item> element. <Item> elements may in turn contain
<Array> elements allowing for the creation of multi-dimensional and
jagged arrays. Nested <Array> elements are identified with array
index notation and any value in @key is ignored.

For the below examples, consider that a custom tag <my:Colors> has
been defined previously

Ex: Simple array

<my:Colors>
<title>Foo</title>
<Array key="colors">
<Item>Red</Item>
<Item>Green</Item>
<Item>Blue</Item>
</Array>
</my:Colors>


In this case, the EL statement ${My.colors[0]} would evaluate to "Red"
and ${My.colors[2]} would evaluate to "Blue"



Ex: Jagged array

<my:Colors>
<title>Foo</title>
<Array key="colors">
<Item>
<Array>
<Item>Pink</Item>
<Item>Orange</Item>
<Item>Purple</Item>
</Array>
</Item>
<Item>Green</Item>
<Item>Blue</Item>
</Array>
</my:Colors>

In this case, the EL statement ${My.colors[2]} evaluates to "Blue", $
{My.colors[0][0]} evaluates to "Pink", and ${My.colors[0]} evaluates
to an array.

This notation has the advantages of allowing more complex arrays and
removes ambiguity as to the question of re-assignment vs. string
concatenation vs. array creation when evaluating repeated parameter
keys. It also will remove ambiguity as to how things like .length
will evaluate (length of array vs. length of strings).

Does this notation satisfy your requirement?
--
clc

[Lev Epshteyn]

On Fri, Oct 9, 2009 at 3:02 PM, goosemanjack <cc...@myspace.com> wrote:

I would contend that we're using XML notation to assign values in a
programming language (the EL).  We're not using DOM traversal or
XPath.

I don't agree with that contention. The invocation model for custom tags *is* XML, not markup that really stands in for Javascript, EL or any other scripting. We need to make our syntax look natural for people who expect it to conform to XML conventions.

Given a tag with two same-name child nodes, I think it is much more natural to assume that the intent is to define two distinct values in order than that one should override the other. I don't see what ambiguity it is you are trying to solve. To me markup like

<foo>
   <bar>a</bar>
   <bar>b</bar>
</foo>

very clearly defines *two* <bar> children of <foo>, and I think a typical Opensocial developer would see it this way.

The proposal you outline below addresses this use case by creating reserved tag names, and making the markup more verbose, so I am strongly opposed to it.

I'd like to hear an argument against having multiple child tags define multiple child values (rather than redefining the same one) before we proceed. This is already in the spec, and we should have a good reason for changing it.

[Jorge Reyes]

I thin that the problem is not just if the syntax looks natural or not. We need to think how the developers are going to use it identify edge cases and think on how we are going to implement this. What I don't like of this part of the spec is that using arbitrary elements do not reflect intent. Let me give you an example some examples.

<script type="text/os-template" tag="myapp:AltGrid">
      <div repeat="Friends" style="background-color: ${ My.Color[Context.Index % My.Color.length] }">${Cur.DisplayName}</div>

</script>

<myapp:AltGrid Friends="${vwerFriends}">

<Color>Red<Color>

</myapp:AltGrid>

lets assume that there is 4 friends the output will be

<div style="background-color:R">Friend 1</div>

<div style="background-color:e">Friend 2</div>

<div style="background-color:d">Friend 3</div>

<div style="background-color:R">Friend 4</div>

Another example of why I strongly believe we should reflect intent  is

<script type="text/os-template" tag="myapp:renderEx">

    <os:Render content="title" />

</script>

<script type="text/os-template" tag="myapp:renderEx">

    ${My.title}

</script>

<myapp:renderEx>

<title>my title</title>

</myapp:renderEx>

What is the difference?

Going back to the discussion on arrays how do I evaluate this

<script type="text/os-template" tag="myapp:renderEx">

    ${My.title}

</script>

<myapp:renderEx>

<title>my title</title>

<title>my title 2</title>

</myapp:renderEx>

This is no longer a string is an array are we going to display it like 

my title, my title 2

or 

my titlemy title 2

or like

Array

I really don't see a way around other that express intent. I'm with Chris on this.

[goosemanjack]

> I'd like to hear an argument against having multiple child tags define
> multiple child values (rather than redefining the same one) before we
> proceed. This is already in the spec, and we should have a good reason for
> changing it.

In order to support your proposed interpretation of parameters as
additive, we would need to create a DOM-like API to support walking
the nodes. There is not that ability current in the EL.
Additionally, we would have to treat all parameters as an array of one
element. It becomes the equivalent of what one would get when
invoking:

document.getElementsByTagName("body");

There is only one <body>, but you would still get an array. It
greatly complicates how the EL would interpret things to use your
proposed DOM-node like behavior. Given a parameter "Title", accessing
simple parameter values would become

${My.Title[0]} instead of the currently specified ${My.Title}.


As far as your statement that "this is already in the spec", that is
not actually the case. The whole point of this proposal is to clarify
the behavior of parameters because it is not clearly defined in the
spec. Shindig may have implemented it that way, but MySpace did not.
We're using a simple hash table and overwriting parameters when
duplicates are found.
--
clc

[Evan Gilbert]

On Mon, Oct 12, 2009 at 11:04 AM, goosemanjack <cc...@myspace.com> wrote:

> I'd like to hear an argument against having multiple child tags define
> multiple child values (rather than redefining the same one) before we
> proceed. This is already in the spec, and we should have a good reason for
> changing it.

In order to support your proposed interpretation of parameters as
additive, we would need to create a DOM-like API to support walking
the nodes.  There is not that ability current in the EL.
Additionally, we would have to treat all parameters as an array of one
element.  It becomes the equivalent of what one would get when
invoking:

document.getElementsByTagName("body");

There is only one <body>, but you would still get an array.

Agreed that internally you would represent these as an array.

 

 It
greatly complicates how the EL would interpret things to use your
proposed DOM-node like behavior.  Given a parameter "Title", accessing
simple parameter values would become

${My.Title[0]}  instead of the currently specified ${My.Title}.

You can still use ${My.Title} - the value of evaluating a list is the merged text content of all of the elements in the array.

 

As far as your statement that "this is already in the spec", that is
not actually the case.  The whole point of this proposal is to clarify
the behavior of parameters because it is not clearly defined in the
spec.  Shindig may have implemented it that way, but MySpace did not.
We're using a simple hash table and overwriting parameters when
duplicates are found.

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.6.2 seems to have fairly clear processing rules.

--

[Jorge Reyes]

On Mon, Oct 12, 2009 at 11:36 AM, Evan Gilbert <uid...@google.com> wrote:

On Mon, Oct 12, 2009 at 11:04 AM, goosemanjack <cc...@myspace.com> wrote:

> I'd like to hear an argument against having multiple child tags define
> multiple child values (rather than redefining the same one) before we
> proceed. This is already in the spec, and we should have a good reason for
> changing it.

In order to support your proposed interpretation of parameters as
additive, we would need to create a DOM-like API to support walking
the nodes.  There is not that ability current in the EL.
Additionally, we would have to treat all parameters as an array of one
element.  It becomes the equivalent of what one would get when
invoking:

document.getElementsByTagName("body");

There is only one <body>, but you would still get an array.

Agreed that internally you would represent these as an array.

 

 

I like more this idea. All the parameters are treated as Arrays. But still I think a syntax expressing porpoise will be less confusing that the existing one. 

 It
greatly complicates how the EL would interpret things to use your
proposed DOM-node like behavior.  Given a parameter "Title", accessing
simple parameter values would become

${My.Title[0]}  instead of the currently specified ${My.Title}.

You can still use ${My.Title} - the value of evaluating a list is the merged text content of all of the elements in the array.

A possible source of confusion here will be that My.Title.length will be 1. To know the length of the title you will need to use My.Title[0].length

If we are going to use this approach. We need to agree how My.Title will be render. I think it should be a coma delimited list.

[goosemanjack]

Once again I have been proven wrong. The only reference I had found
previously was in os:Render

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.12

"4.Replace the os:Render tag with child nodes of all the tags found in
step (3)."

To me the logical interpretation was to concatenate the strings, not
cycle an array. Even though the spec in the location your have
pointed out seems to indicate that the original behavior is to treat
the multiple parameters as DOM element list, we believe this is a spec
bug. It conflicts with the general expressions definition that
states: "Expressions are usually evaluated as strings."

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.6

This overloading of the EL definition with strings, objects, and DOM-
like elements adds too much complexity with no clear benefit,
especially in light of the fact that there are multiple other methods
of generating list and array-like structures.

The interpretation is both confusing to developers and limited in
terms of functionality. It's confusing to developers because:

1) In some cases tags load objects into DataContext (DP tags)
2) In some cases tags load text into DataContext (os:HttpRequest)
3) In some cases tags load string-coorced object values into
DataContext (params with EL)
4) In some cases tags would create simple Arrays (repeated parameters)

Furthermore, in the model as interpreted by Shindig why would
attributes and elements with matching names be treated differently?
They would also have to be added to an array.

The parameter model as interpreted by Shindig is limiting in that it
only allows for one-dimensional arrays.

> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

[Evan Gilbert]

On Tue, Oct 13, 2009 at 9:41 AM, goosemanjack <cc...@myspace.com> wrote:

Once again I have been proven wrong.  The only reference I had found
previously was in os:Render

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.12

"4.Replace the os:Render tag with child nodes of all the tags found in
step (3)."

To me the logical interpretation was to concatenate the strings, not
cycle an array.  Even though the spec in the location your have
pointed out seems to indicate that the original behavior is to treat
the multiple parameters as DOM element list, we believe this is a spec
bug.  It conflicts with the general expressions definition that
states: "Expressions are usually evaluated as strings."

It goes on to state "The only exception is when expressions are in attributes without additional text content"

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Templating.html#rfc.section.6

This overloading of the EL definition with strings, objects, and DOM-
like elements adds too much complexity with no clear benefit,
especially in light of the fact that there are multiple other methods
of generating list and array-like structures.

Think there are two parts of expression processing:

1. Evaluating the expression. The result is a variable, and can result in many types of objects - booleans, strings, objects, DOM.

2. Using the results of evaluation. In most cases, this takes the expression and puts it into a text node or an attribute node value. However, if you're processing a value for a @if, @repeat, @cur, or passing to a template, you cast to an appropriate value. The @repeat attribute doesn't work unless we support list types, for example.

--

[goosemanjack]

So let's circle back around on the original proposal. It looks like
the only item for discussion is the treatment of repeated elements
(item #2 in proposal). The other four appear to not be in contention.

Item 2 (repeated elements) is a point of discussion because Shindig
and the 0.9 spec treat parameters like XML elements where they create
a node-list (faux array) that can be walked.

MySpace wants to interpret parameters more like ColdFusion, where each
element is a repeated setting of a single variable.

http://www.adobe.com/devnet/server_archive/articles/using_cf_variables.html

If the os:Var proposal is accepted we're willing to concede on the
interpretation of repeated elements. It would bring a more
intentional syntax for declaring arrays within the context of template
parameters, which satisfies our needs.

Does that sound like something acceptable to everyone else?

On Oct 14, 10:30 am, Evan Gilbert <uid...@google.com> wrote:
> On Tue, Oct 13, 2009 at 9:41 AM, goosemanjack <cc...@myspace.com> wrote:
>
> > Once again I have been proven wrong.  The only reference I had found
> > previously was in os:Render
>

> >http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

>
> > "4.Replace the os:Render tag with child nodes of all the tags found in
> > step (3)."
>
> > To me the logical interpretation was to concatenate the strings, not
> > cycle an array.  Even though the spec in the location your have
> > pointed out seems to indicate that the original behavior is to treat
> > the multiple parameters as DOM element list, we believe this is a spec
> > bug.  It conflicts with the general expressions definition that
> > states: "Expressions are usually evaluated as strings."
>
> It goes on to state "The only exception is when expressions are in
> attributes without additional text content"
>
>
>

> >http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Ope...

> ...
>
> read more »

[Lev Epshteyn]

I believe it's actually Point 1 of the original proposal on which we are disagreeing...

Unless I missed another version of the proposal deeper in the conversation.

--

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-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[goosemanjack]

Yes, you are correct in that the point of discussion is around item 1.

Did you have any feedback on the <os:Var> proposal
http://wiki.opensocial.org/index.php?title=Temporary_vars_in_templates_and_data_pipelining
(thread) http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/8b0e50a2a429f44b?hl=en

If we can get <os:Var > approved then this discussion can be moot
because the behavior you are describing vs. the behavior we are
describing can co-exist cleanly.
--
clc

On Nov 2, 5:55 am, Lev Epshteyn <le...@google.com> wrote:
> I believe it's actually Point 1 of the original proposal on which we are
> disagreeing...
>
> Unless I missed another version of the proposal deeper in the conversation.
>
> On Mon, Oct 26, 2009 at 7:49 PM, goosemanjack <cc...@myspace.com> wrote:
> > So let's circle back around on the original proposal.  It looks like
> > the only item for discussion is the treatment of repeated elements
> > (item #2 in proposal).  The other four appear to not be in contention.
>
> > Item 2 (repeated elements) is a point of discussion because Shindig
> > and the 0.9 spec treat parameters like XML elements where they create
> > a node-list (faux array) that can be walked.
>
> > MySpace wants to interpret parameters more like ColdFusion, where each
> > element is a repeated setting of a single variable.
>

> >http://www.adobe.com/devnet/server_archive/articles/using_cf_variable...

> ...
>
> read more »

[goosemanjack]

Patch created
http://codereview.appspot.com/151062

Also updated wiki page with patch text
http://wiki.opensocial.org/index.php?title=Clarify_Custom_Tag_Template_Parameter_Behavior
--
clc

On Nov 2, 10:40 am, goosemanjack <cc...@myspace.com> wrote:
> Yes, you are correct in that the point of discussion is around item 1.
>

> Did you have any feedback on the <os:Var> proposalhttp://wiki.opensocial.org/index.php?title=Temporary_vars_in_template...
> (thread)  http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

> ...
>
> read more »

[Lev Epshteyn]

Looked over the patch. See my comments inline:

http://codereview.appspot.com/151062/diff/1/2

Generally, I think there are a number of things introduced that we never discussed. If those were removed, I'd be +1 on this. Parts I like are:

• Case insensitivity for attributes, child nodes
• Specifying how namespaces work with child nodes in ${My}
  
• Specifying attribute precedence over child nodes for ${My}
• Specifying that multiple child nodes can be used to create an array
  

> ...
>
> read more »

[goosemanjack]

I replied on the alternate thread you started. I'll also try to reply
in the review.

http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/7690ad30260fc7db

The new introductions were to make sure we were covering all the edge
cases. The original thread still left a number of things unclear, and
I wanted to make sure there was no ambiguity.

Please read my reply on the alternate thread and give your feedback.
My preference would be to make sure we clarify behavior on all the
additional cases identified, rather than leave these options open for
interpretation.
--
clc

On Nov 10, 10:34 am, Lev Epshteyn <le...@google.com> wrote:
> Looked over the patch. See my comments inline:
>
> http://codereview.appspot.com/151062/diff/1/2
>
> Generally, I think there are a number of things introduced that we never
> discussed. If those were removed, I'd be +1 on this. Parts I like are:
>

>    - Case insensitivity for attributes, child nodes
>    - Specifying how namespaces work with child nodes in ${My}
>    - Specifying attribute precedence over child nodes for ${My}
>    - Specifying that multiple child nodes can be used to create an array

>
> On Mon, Nov 9, 2009 at 3:55 PM, goosemanjack <cc...@myspace.com> wrote:
> > Patch created
> >http://codereview.appspot.com/151062
>
> > Also updated wiki page with patch text
>

> >http://wiki.opensocial.org/index.php?title=Clarify_Custom_Tag_Templat...

> ...
>
> read more »