Modify the Wink Thermostat Translator to be aligned with OCF format

[tjaffri]

44 is creating the thermostat schema in OCF format.

In parallel, we need to update one translator (let's pick the Wink Thermostat Translator for ease) to implement that schema. This includes:

Updating the manifest file

The manifest.xml needs to reference the OCF schema(s), where it currently only references a single AllJoyn schema.

For example:

<schemas>
      <schema id="org.opent2t.sample.thermostat.superpopular" main="true" type="OCF" />
      <schema id="oic.r.temperature" type="OCF" />
      <schema id="oic.core" type="OCF" />
      <schema id="oic.baseResource" type="OCF" />
  </schemas>

Note that we are OK (for now) duplicating the fact the dimming and binary will likely be $ref inside org.OpenT2T.Sample.SuperPopular.Lamp but will also be duplicated under schemas. We can discuss this further at a later date.

Updating the methods in the translator itself

We need to update the translator methods to correspond to the RAML (get/put pattern) in OCF.

[tjaffri]

@jasongin and @sanjaiganesh I was doing some other dir structure renaming work with @arjun-msft and @jeanpa and we STUBBED OUT some of this stuff. I haven't made all the changes like updating the test automation and the actual deviceTranslator implementation but let's huddle to see if you can reuse some of my stub.

[jasongin]

We need to clarify the usage of <schema> elements in the manifest.

• The first element in the example above does not include a filename extension -- does it refer to the .raml or .json file?
• A .raml file may reference more than one top-level .json schema, either because it defines multiple endpoints or because different verbs for the same endpoint use different schemas. (Though it appears neither of those are common practice for OCF, I wouldn't want the design to rely on that assumption.) Should each of them be listed separately in the manifest?
• What about non-top-level .json schema references, should they be listed also?

In my opinion, the manifest only needs to reference the .raml file. I don't see any reason to duplicate all of the direct and indirect references to .json schema files (a flattened schema dependency tree) in the manifest.

[tjaffri]

Here are some notes on the <schema> elements in the manifest:

1. Really all we need in the manifest is a way to locate the .js file in the manifest directory, specifically the name of the main schema. So in the given example all we need is org.opent2t.sample.thermostat.superpopular
2. After the .js file is loaded, specifically for the given example the file is here that file decides which reader to load (OCF vs AllJoyn)
3. The reader, once loaded (in this case the OCF reader) needs to do the following things:
   1. Parse the RAML to get the name of the endpoint (e.g. /foo:)
   2. Parse the RAML to get the verbs in the endpoint (e.g. GET and POST)
   3. Derive JavaScript methods names from the above info, e.g. foo_get() and foo_post(value)
   4. Parse the RAML to find the schemas referenced in it. Walk the schema tree to derive the type of value that's passed in to post, and returned from get/post.

Let's stick with the above for now, which should serve our purposes. Clearly we need to keep thinking about the manifest.xml format but we will learn once we have things working e2e.

[tjaffri]

Basic version of this is done, so I am closing it out. Will file a new issue to finish this implementation with any other schema attributes we want to add.