Currently for a property definition in a Web Thing Description as below:

...
    "temperature": {
      "type": "number",
      "links": [{"href": "/things/pi/properties/temperature"}]
    }
...

a response to a GET request on the Property resource looks something like:

{
  "temperature": 21
}

where the payload is a JSON object with a map representation of the property's name and value. The payloads of PUT requests and responses also follow the same format.

@egekorkan has pointed out that if parsed as a W3C Thing Description using the latest W3C specification (assuming the links were parsed as forms) the default would be that the payload for the Property resource would just contain the value:

21

I believe the rationale for originally wrapping this as an object in the Mozilla specification was:

1. In older versions of JSON an integer or string on its own would not be valid JSON, so it needed to be wrapped in an object.
2. It helps with consistency for Properties resources and the setProperty and propertyUpdate WebSocket messages.

In order to move closer to the W3C specification we could consider removing this object wrapper for Property resources (which is now valid JSON). The Properties resource would still use a map for requests and responses, as is already the default for top level forms with readallproperties, writeallproperties, readmultipleproperties, or writemultipleproperties operations in the W3C spec.

Problems I can forsee with this are:

1. This would be a backwards incompatible change which could cause breakage (we'd have to just live with that)
2. Action, Event, Actions and Events resources all use similar wrappers and I'm not sure how we'd deal with those.