Open Blobonat opened 2 years ago
I guess we could put the @contexzt in either of the two positions (unless we add to the spec something we've been discussing in ETSI ISG CIM where the NGSI-LD API is defined - prohibiting the @context to be anywhere except the toplevel of a payload body).
In either case, if you receive a notification with 100 entities in the "data" array, and the @context is part of the items of that array, then you'd receive 100 copies of the exact same @context. That's an important waste of bandwidth and I'll talk to NEC about this. I'm confident they'll see my thinking and change Scorpio accordingly.
I'll post any news about this in this issue.
Just got the preliminary OK from NEC (owners of Scorpio) to do it "my way" - just preliminary for now. Well discuss this in ETSI ISG CIM and amend the API spec accordingly. A new release of the API spec is due just after Christmas, so it just might be part of that new version.
Once we have a definitive agreement, I'll post again (well, I'll try to remember!)
Hi,
I noticed a small deviation between Scorpio and Orion-LD with the placement of @context inside a notification with
endpoint.accept: "application/ld+json"
: Orion-LD places the@context
on the top level and Scorpio indata
for each entity.Orion-LD behavior:
Scorpio behavior:
I haven't found any requirement regarding the placement of the
@context
in the NGSI-LD API spec, but some FIWARE components such as Cosmos expect the format as used by Scorpio. Is there any way, e.g. the usage of areceiverInfo
inside a subscription, to influence the format used by Orion-LD?