I find this name and description misleading; dotted names are valid keys and they should be parsed. I think you are actually meaning to say something like this:

@simon-ess another suggestion to avoid the impression that dotted names are never valid keys:

In this way, the test seems like you are purely testing for the absence of functionality. I think it is more motivating if you contrast it with the desired behavior:

This is also why I suggested "No Masking" for the test name.

The only reason I caution this approach is that it still does not define what to do in the case that you have a key of the form a.b: is that a valid key or not? This is relevant for us because the java and python versions disagree: this is undefined behaviour from the spec.

That is, what should the expected output of the following be? At the moment the spec does not define that.

data:
  a.b: c
template: '{{a.b}}'

I think the spec defines it (in the human-oriented text), but does not test for it explicitly. If you follow the human-oriented text to the letter, I agree with you that the output should be the empty string. I also think that the other tests already imply this; they just don't enforce it.

The reason I'm hesitant to add your original version of this test, is that it actively prevents implementations from being more lenient towards their users as an added service. I understand that this is exactly what you are trying to achieve, but I'm not yet convinced that this will make the world a better place. Many implementations have extras outside of the spec, and I think this is a good thing in general. Surely, mustache.java is not harming anyone by allowing a fallback to a property by the name a.b in the context?

What we did that caused us to run into this was the following: we have a java backend that performs some templating action, and we wanted to provide a python command-line utility that did the same for users to test our templating service. The problem is, this difference means that we cannot do that; moreover, the proposed spec fix would not have resolved this issue for us either.

In a sense, the java implementation follows the letter of the spec, but not the spirit. If it is intended that keys not have periods in them, then why not specify that and enforce it?

It's not the end of the world for us; we can change the data that we use. However, the undefined behaviour in the specification means you can't at the moment have a java and python client produce the same output on the same input. Is it the end of the world? No. Can it cause people issuse? Yes.

I'm happy with the more explicit specification that removes the ambiguity. I think you should have both test cases mentioned in here. Have to figure out how to make it easy for folks to get backwards compatibility. For instance, I can imagine folks passing in an object that has all paths expanded before handing them to mustache.java for performance reasons.

@spullara Maybe a customization flag (old/new behavior)?

@bobthecow do you agree both tests should go in? Then I'll merge this, after recompiling the JSON.

Any news on this? I work with @simon-ess , and we would appreciate some conclusion to this.

@anderslindho and @simon-ess, apologies for the long silence. I was waiting for a reply by @bobthecow, but it probably escaped his attention and then it escaped mine as well. However, we can decide without his input because @spullara and I already agree.

Concluding, we will merge this. I can do it in the week of June 17-21.