for example, we don't check if all the op values are implemented in an implementation

The following TD shows the error of multiLangConsistency even though all titles and descriptions have de language.

{
   "@context":[
      "https://www.w3.org/2019/wot/td/v1",
      {
         "cov":"http://www.example.org/coap-binding#"
      },
      {
         "saref":"https://w3id.org/saref#"
      }
   ],
   "securityDefinitions":{
      "basic_schema":{
         "scheme":"basic",
         "descriptions":{

         },
         "description":"Basic sec schema",
         "in":"query",
         "name":"querykey"
      }
   },
   "security":[
      "basic_schema"
   ],
   "@type":[
      "saref:LightSwitch"
   ],
   "titles":{
      "de":"Deutscher Titel"
   },
   "title":"English title",
   "descriptions":{
      "de":"Deutsche Beschreibung"
   },
   "description":"English description",
   "properties":{
      "echo":{
         "observable":false,
         "forms":[
            {
               "op":[
                  "readproperty"
               ],
               "href":"/echo",
               "contentType":"application/json"
            }
         ]
      }
   }
}

It seems, that 'old' TDs with the interaction term are validated correct which should not be the case or at least provide a warning that non properties, actions, or events term was used:

Due to ajv, the same error message is printed multiple times

To reproduce the issue.

1. Go to http://plugfest.thingweb.io/playground/
2. Try to select an example from drop-down list
3. Dialog appears: e.g., "The JSON could not be fetched from the address:
   https://raw.githubusercontent.com/thingweb/thingweb-playground/master/WebContent/Examples/Valid/simple.json"

With a checkbox, it should be possible to do a clear log before each validation so that only the most recent log messages are shown.

@adriankast can you have a look at it?

It can happen that two JSON Schemas for two assertions can have the same also field. For example, td-vocab-security--Thing and td-vocab-security--Form have both td-arrays_security in the also array. The results will have thus twice td-arrays_security. This needs to be handled

Hi,

The playground states the following error

data.support should match format "uri"

for input like

"support": "none"

support can be now of type string (used to be uri though)

1. In https://github.com/thingweb/thingweb-playground/blob/master/playground-web/config.js the code needs to be changed to change the deployment.
2. The environment variables need to passed in the start command. It would be better to do it via dotenv package: https://www.npmjs.com/package/dotenv
3. Needs more testing but there are CORS problems

this happens because uniqueness is checking for non duplicates and having nothing to check for duplicates passes uniqueness check

Due to the multiple usage of td-json-open and child assertions of it (td-json-open_xyz) in both automatic and manual assertions it is not merged correctly, which results in 337 assertions if a single TD is assertion tested. If multiple TDs are under test, the result merge probably also merges the duplicates and 335 assertions are reported.

I tried to use the offline version for validation both in Safari and Chrome.
The page loads, the "clear log" button works,
however the validate button does not perform any action.

The section 'Script based Thing Description Validation' inside the README should be adjusted, because the path "./WebContent/Examples/Bundang/Valid/MyLampThing.jsonld" doesn't exist.

@type should allow both string and an array of strings. So far, arrays are seen as error in the TD

Hi there! This is more of a question than an issue.
I'm wondering what the idea behind the manual.csv assertions is.
I was looking in the code. It appears to just append them to the results array. I find this a bit odd, the status column is null than.

The following TD was validated correctly, however, the actions definition is not correct:

{
    "@context": [
        "https://w3c.github.io/wot/w3c-wot-td-context.jsonld",
        "https://w3c.github.io/wot/w3c-wot-common-context.jsonld",
        {
            "iot": "http://iotschema.org/",
            "http": "http://www.w3.org/2011/http#"
        }
    ],
    "base": "http://159.203.213.90:1880",
    "id": "urn:uuid:c3068abb-7781-4ab4-9c0b-012408e9e758",
    "@type": [
        "Thing",
        "iot:MotionControl"
    ],
    "name": "Motion Sensor",
    "properties": {"MotionState": {
        "writable": false,
        "observable": true,
        "@type": [
            "Property",
            "iot:MotionDetected"
        ],
        "type": "array",
        "items": [{
            "type": "object",
            "properties": {
                "n": {
                    "type": "string",
                    "const": "5700"
                },
                "vb": {
                    "@type": ["iot:stateData"],
                    "type": "boolean"
                }
            }
        }],
        "forms": [
            {
                "href": "/3300/2",
                "mediaType": "application/json",
                "rel": "readProperty",
                "http:methodName": "GET"
            },
            {
                "href": "/3300/2",
                "mediaType": "application/json",
                "rel": "writeProperty",
                "http:methodName": "POST"
            },
            {
                "href": "mqtt://0m2m.net:1883/plugfest/subscriptions/Motion",
                "mediaType": "application/json",
                "rel": "observeProperty",
                "mqtt:commandCode": 8
            }
        ]
    }},
    "actions": {
        "connect": {"@type": ["mqtt:connect"]},
        "forms": [{
            "href": "mqtt://0m2m.net:1883",
            "mqtt:commandCode": 1
        }]
    }
}```

td-vocab-description.json should be named differently, like td-vocab-description_dataschema.json

Firstly, the link behind Script Validation button is not there anymore after restructuring. Also, I think we can say that it is a proper cli and not just some basic scripts. So the text should change to Playground CLI and it should point to the correct link (https://github.com/thingweb/thingweb-playground/tree/master/playground-cli)

After many validations, the console gets really full. There needs to be a button to clear console and a way to see the history of validations.

My assumption is that prefixed JSON-LD examples like the following should be valid.

{
  "@context": {
    "wot":"http://w3c.github.io/wot/w3c-wot-td-context.jsonld#",
    "td": "http://www.w3c.org/wot/td#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "sch": "http://schema.org"
  },
  "@type": "td:Thing",
  "wot:name":"echonet",
  "wot:interactions": [
       {
       "@type": "wot:Property",
       "wot:name": "operationStatus",
       "wot:valueType": { "@type": "xsd:boolean" },
       "wot:writable": true
      }
  ]
}

see https://github.com/w3c/wot/blob/master/proposals/td-lifecycle/Echonet_def0.jsonld

It seems the tool expects
"wot:name":"echonet"
to be
"name":"echonet"

et cetera...

Following TD from Fujitsu does not define the namespace {"iot": "http://iotschema.org/"} for iot:Temperature, iot:Humidity, etc, but it passes all validations in http://plugfest.thingweb.io/playground/

{
"@context": ["https://w3c.github.io/wot/w3c-wot-td-context.jsonld"],
"@type": "Thing",
"name": "Fujitsu-WiFiAgent240AC4114764",
"id": "urn:dev:wot:com:fujitsu:wifiagent",
"base" : "http://192.168.1.21/Things/Property/",
"properties": {
"Temperature": {
"@type": "iot:Temperature",
"type": "object",
"properties": {
"temperature":{"type":"number"},
"rssi":{"type":"number"}
},
"writable": false,
"observable": false,
"forms": [{
"href" : "temperature",
"mediaType": "application/json"
}]
},
"Humidity": {
"@type": "iot:Humidity",
"type": "object",
"properties": {
"humidity":{"type":"number"},
"rssi":{"type":"number"}
},
"writable": false,
"observable": false,
"forms": [{
"href" : "humidity",
"mediaType": "application/json"
}]
},
"AirPressure": {
"@type": "iot:AirPressure",
"type": "object",
"properties": {
"airPressure":{"type":"number"},
"rssi":{"type":"number"}
},
"writable": false,
"observable": false,
"forms": [{
"href" : "airPressure",
"mediaType": "application/json"
}]
},
"Dust": {
"@type": "iot:Dust",
"type": "object",
"properties": {
"dust":{"type":"number"},
"rssi":{"type":"number"}
},
"writable": false,
"observable": false,
"forms": [{
"href" : "dust",
"mediaType": "application/json"
}]
},
"AllSensorData": {
"@type":"iot:AllSensor",
"type": "object",
"properties": {
"temperature":{"type":"number"},
"humidity":{"type":"number"},
"airPressure":{"type":"number"},
"dust":{"type":"number"},
"rssi":{"type":"number"}
},
"writable": false,
"observable": false,
"forms": [{
"href" : "allSensorData",
"mediaType": "application/json"
}]
}
},
"actions":{},
"events":{}
}

Could the filenames be changed to another one without ":" because Windows cannot handle them?

I propose that the coloring for validation (with/or without default) and errors could/should be aligned with the drop-down shown for the examples.

see http://plugfest.thingweb.io/playground/

• green: all fine
• orange: missing defaults
• red: errrors

WebContent/td-schema-full.json is different from the one in the TD spec. Which one should be updated?

Since the error messages can be long sometimes, the text containing the error message should be wrapped in the console to match the width of the console

td-vocab-title--DataSchema.json and td-vocab-description--DataSchema.json are wrong, they don't cover the possibility of having title or description as a property name

On the playground should be a button "submit as gist", which allows submitting the TD being edited to the Thingweb Github account. Unless other advise I would implement:

• GOOD: an node.js script listening on a port which accepts Description+Name as input, does the request to the GitHub API, responses with Status and the gist ID.
  + The private API Token can be kept secret
  - The script needs to be hosted by an node.js environment on the playground/another server
• Alternative: The request is made directly in the playground web script. This would allow extraction of the API key, which can be used to create/update/delete all Gists of the account.
  In both cases the API Token will be inserted by a CD process and not visible in the repository.

In Firefox, the examples drop-down has no colors to indicate whether they are valid, warning or invalid examples. However, in Chrome it works well. @adriankast could you have a look?

P.S. I am not able to paste screenshots since when I click on screenshot, the dropdown closes :/

I assume this is a running task as long as the TD itself is changing.

Valid examples linked on http://plugfest.thingweb.io/playground/ might need to be updated from time to time.

JSON Schema validation error occurs at securityDefinitions, when mandatory vocabularies defined at https://w3c.github.io/wot-thing-description/#sec-security-vocabulary-definition is omitted, even if the default value is defined at https://w3c.github.io/wot-thing-description/#json-serializiation-section.

For example, following fails:

  "securityDefinitions": {"bearer_sc": {
    "scheme": "bearer",
    "format": "jwt",
    "alg": "ES256",
    "authorization": "https://w3c.p-wot.com:8443/auth"
  }},
  "security": ["bearer_sc"],

with error message:

> data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'] should have required property 'in', data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'].scheme should be equal to one of the allowed values, data.securityDefinitions['bearer_sc'] should match exactly one schema in oneOf

while following passes:

  "securityDefinitions": {"bearer_sc": {
    "scheme": "bearer",
    "in": "header", 
    "format": "jwt",
    "alg": "ES256",
    "authorization": "https://w3c.p-wot.com:8443/auth"
  }},
  "security": ["bearer_sc"],

As the title states the editor window is pretty small for displays with high resolution with a pretty large unused white bar at the lower display part (see screenshots). Would it be possible to make the editor window variable in size or adapt the editor size to the display resolution? Maybe it would also be a possibility to adapt the layout to a column layout with the TD on the left and the options and validation output on the right side. These screenshot were taken with a display resolution of 1440x2560 (first) and 3840 × 2160 Pixel (second).

It should be possible to automatically generate an OpenAPI description of a Thing by using the Thing Description as input.
This description can be used to visualize an API view of a Thing and extend tool support by importing it e.g. to postman.

Functionalities should be added stepwise:

• url + method based path generation
• names transfer (title, description, ...)
• generate example payloads
• add tests in postman

Is developed under: https://github.com/adriankast/thingweb-playground/tree/openAPI

Placeholder for new assertions to test

• @context and @type in data schema and security
• td-data-schema-object
• When the value of readOnly member is true in an instance of PropertyAffordance, the value(s) in the op term member of the forms MUST NOT contain writeproperty. Similarly, when the value of writeOnly member is true in an instance of PropertyAffordance, the value(s) in the op term member of the forms MUST NOT contain readproperty.
• td-ns assertions: these are about checking whether the different keys in a context object are unique and whether the context links are refereancable

Hi,

some examples that fail

Example 1

"@context": {
		"iot": "http://iotschema.org/"
}

Message: data['@context'] should be array, data['@context'] should be string, data['@context'] should be equal to one of the allowed values, data['@context'] should match exactly one schema in oneOf

Example 2

"@context": [{"iot": "http://example.org/iot"}]

Failure Message: > data['@context'][0] should be string, data['@context'][0] should be equal to one of the allowed values, data['@context'] should contain a valid item, data['@context'] should be string, data['@context'] should be equal to one of the allowed values, data['@context'] should match exactly one schema in oneOf

The assumption seems to be that it is always in the following way

"@context": ["http://www.w3.org/ns/td",
                {"iot": "http://example.org/iot"}]

Even the order seems to count... for example changing the order gives an error for

"@context": [{"iot": "http://example.org/iot"}, "http://www.w3.org/ns/td"]

"http://www.w3.org/ns/td" needs to come first to be valid.. i don't think these restrictions are necessary

I fed in a Thing Description with a typo in the description keyword (which was desciption), and it was validated to Ok. Is that an intended behaviour?

In the example TDs included in the playground-core package, the field name http:methodName appears in several files.
Is it an error and should be htv:methodName or am I missing something?
https://w3c.github.io/wot-binding-templates/#http-vocabulary
The properties are part of these valid TD examples:

• formOpArray
• formOpArrayWithDefaults
• JsonLdThing
• rootForms

In the TD spec it is allowed to have an interaction with "readOnly":true and have an op in the same interaction's forms with writeproperty. Similar with writeOnly or observable. I think that these should be checked in the additional checks section.

the op for property/action/event are not validated properly since it checks whether all the actions' all forms have an op. The if clause should be moved to form level

@egekorkan So far, no validation is be done for a relative provided href and base URI. Also the correct "/" has to be checked.
E.g., "base":"http://test-example.net" and "href":""test" is not correct since there is a "/" missing at the begin of href or end of the base uri