eclipse-thingweb / playground Goto Github PK
View Code? Open in Web Editor NEWBrowser or Node.js based tool for validating and playing with W3C Thing Descriptions
Home Page: https://playground.thingweb.io/
License: Other
Browser or Node.js based tool for validating and playing with W3C Thing Descriptions
Home Page: https://playground.thingweb.io/
License: Other
WebContent/td-schema-full.json is different from the one in the TD spec. Which one should be updated?
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":{}
}
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
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
}]
}
}```
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.
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
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:
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 serverthe 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
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.
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"
}
]
}
}
}
Placeholder for new assertions to test
@context
and @type
in data schema and securityAfter 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.
@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
Could the filenames be changed to another one without ":" because Windows cannot handle them?
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"],
td-vocab-description.json should be named differently, like td-vocab-description_dataschema.json
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).
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.
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
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)
for example, we don't check if all the op values are implemented in an implementation
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?
@type should allow both string and an array of strings. So far, arrays are seen as error in the TD
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.
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.
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/
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?
Due to ajv, the same error message is printed multiple times
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:
this happens because uniqueness is checking for non duplicates and having nothing to check for duplicates passes uniqueness check
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...
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
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:
Is developed under: https://github.com/adriankast/thingweb-playground/tree/openAPI
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 :/
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.
To reproduce the issue.
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.