Is your feature request related to a problem? Please describe.
We should validate the following when a user creates or edits an NGSI entity: id and type values, attribute names. In fact, both NGSI v2 and LD restrict what's allowed---though in slightly different ways. So a Context Broker may reject an entity the user created/edited if there's no validation in place. Also, Quantum Leap may fail to store entity data if type and attribute names can't be mapped cleanly to table/column names.
Describe the solution you'd like
Put in place some validation so the entity is valid under both NGSI v2 and LD. Also make sure Quantum Leap will be able to save entity data to the DB.
Validate the entity ID field by checking all the conditions below hold true:
it's a valid URI
it starts w/ "urn:nsgi-ld:"
its length <= 256
it only contains ASCII chars, except for: control characters, whitespace, &, ?, / and #
Validate both the content of the entity type field and each attribute name by checking all the conditions below hold
ASCII alphanumeric, plus _
first char is not a digit
length <= 256
Describe alternatives you've considered
Surely we could skip validation and just show the user whatever error Context Broker throws back. But the situation is trickier if you throw Quantum Leap in the mix. In fact, the user could create an entity that Context Broker accepts but Quantum Leap is then not able to store in the DB b/c e.g. column name restrictions. Now there's no easy way to tell the user something is wrong with the entity definition since the error would show up in Quantum Leap after Context Broker sent on the first entity---this is a service-to-service exchange where there's no user interaction.
Additional context
"Field syntax restrictions" section of the NGSI v2 spec
Is your feature request related to a problem? Please describe.
We should validate the following when a user creates or edits an NGSI entity:
idandtypevalues, attribute names. In fact, both NGSI v2 and LD restrict what's allowed---though in slightly different ways. So a Context Broker may reject an entity the user created/edited if there's no validation in place. Also, Quantum Leap may fail to store entity data if type and attribute names can't be mapped cleanly to table/column names.Describe the solution you'd like
Put in place some validation so the entity is valid under both NGSI v2 and LD. Also make sure Quantum Leap will be able to save entity data to the DB.
Validate the entity ID field by checking all the conditions below hold true:
&,?,/and#Validate both the content of the entity type field and each attribute name by checking all the conditions below hold
_Describe alternatives you've considered
Surely we could skip validation and just show the user whatever error Context Broker throws back. But the situation is trickier if you throw Quantum Leap in the mix. In fact, the user could create an entity that Context Broker accepts but Quantum Leap is then not able to store in the DB b/c e.g. column name restrictions. Now there's no easy way to tell the user something is wrong with the entity definition since the error would show up in Quantum Leap after Context Broker sent on the first entity---this is a service-to-service exchange where there's no user interaction.
Additional context
"Field syntax restrictions" section of the NGSI v2 spec
Ch 5 of the NGSI LD spec---especially section 5.2.4