No validation of member values in accordance with their data type

[jason-fox]

Specification states:

5.5.4 JSON-LD validation
All the operations that take a JSON-LD document as input shall process such JSON-LD
document as follows:
• If the request payload body is not a valid JSON document then an error of type InvalidRequest shall be raised.
• If the data included by the JSON-LD document is not syntactically correct, according to the @context or the API Data type definitions, then an error of type BadRequestData shall be raised. For the avoidance of doubt, this includes validation of member values in accordance with their data type, for instance DateTime, and validation of each Relationship's target object which shall be a syntactically valid URI.

The following is therefore invalid since the datetime is not a date - but parses correctly.

curl -X POST \
  'http://localhost:1026/ngsi-ld/v1/entities/' \
  -H 'Content-Type: application/ld+json' \
  -d '{
    "id": "urn:ngsi-ld:Building:something",
    "type": "Building",
    "sillyDate": {
    "type": "Property",
    "value": {
        "@type": "DateTime",
        "@value": "" 
    }
  },
    "@context": "https://fiware.github.io/tutorials.Step-by-Step/data-models-context.jsonld"
}'

it should return BadRequestData

[kzangeli]

Not sure this is an issue - I will take it up with ETSI CIM for discussion.

The value of an attribute can be anything, there is no semantics inside the value (afaik).
In this case the value of "sillyDate" is a JSON object.

Where I believe this rule should apply is when "sillyDate" appears in the @context, something like this:

"@context": {
    "sillyDate": {
        "@id": "...",
        "@type": "DateTime"
    }
}

With a context like that, the following payload data should give an error:

{
    "id": "urn:ngsi-ld:Building:something",
    "type": "Building",
    "sillyDate": {
        "type": "Property",
        "value": ""
  }
}

However, this is advanced error handling.
Lots of higher priority issues to take care of before bothering about this particular one.

[kzangeli]

I added a functest today (Feb 23 2021) for DateTime properties, including error handling.

I believe the issue has been fixed, please try again and close the issue if the broker is working properly (for DateTime)

[jason-fox]

Where I believe this rule should apply is when "sillyDate" appears in the @context, something like this:

"@context": {
    "sillyDate": {
        "@id": "...",
        "@type": "DateTime"
    }
}

But in normalized NGSI-LD sillyDate isn't a DateTime anyway - it is a JSON object with a value and a type - hence your input @context is incorrect. This is the reason the validation has to run on the object @type within the value.