[Fiware-ngsi] DiscoverContextAvailability

[Tobias Jacobs]

Hi Denes,

We register attributes when doing registerContext. However, the attributes does not have initial value. If someone queries them, what should the system give back?
I think that the response should be the same as if nothing had been registered.

What we might not have discussed about yet is what should be returned if a queried attribute value is not available.
To us it makes sense just to return an empty queryContextResponse then. Also because there is no errorCode defined for missing attribute values.

Best
Tobias

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Montag, 23. April 2012 10:31
To: Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu
Subject: RE: DiscoverContextAvailability

Hi Tobias,

I agree with the below proposals. There is another question however.
We register attributes when doing registerContext. However, the attributes does not have initial value. If someone queries them, what should the system give back?

Best,
Dénes


From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]<mailto:[mailto:Tobias.Jacobs at neclab.eu]>
Sent: Tuesday, April 17, 2012 5:38 PM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: DiscoverContextAvailability

Hi Denes,

Please find my answers inline.

Best
Tobias


Hi Tobias, all,

Since I don't see any other meaningful solution, I agree.
If we go down this road, there are some other open questions:


-          All items (except the ProvidingApplication) in the ContextRegistrationList are optional. As I understand either the EntityIdList AND ContextRegistration or the ContextMetadata is present.

In my opinion it is even possible that only the ProvidingApplication is present. This would correspond to the registration of this providing application, without getting more specific on which kind of context information the application can provide.

What should happen when we "update the metadata of the providing application" and no EntityIds are present, as they are not necessary? How does this information relate to the ContextElements?

This would for example mean "The reliability of the providing application has increased (and this holds for all information the application provides)". Would e.g. make sense when a car moves out of the underground parking and now has GPS reception again.


-          If we give registrationId, it means we update a previous registration. What is the exact point of it? We already have an updateContext, what is the difference of this update of registration?

Doing a registration means to announce that a certain application (rather Agent, Device) can provide certain context information. In order to change or cancel such registrations, a registration Id is used.


Best,
Dénes



Dear All,

The second problematic part from NGSI-9 is the Discover Context Availability

If we check, the request contains an EntityId list as well as an Attribute List.

-       There is already a problem: attributes are identified by ID and Name. Here, the list is just an array of String, containing the names only.

                I have not yet understood where the problem is. An NGSI-10 queryContext has the same parameters, the only difference to the NGSI-9 discoverContextAvailability is that the latter function returns pointers to Agents that can provide the requested information, while the further returns the information itself.

However, there is the response, which introduces more ambiguity. The response contains a LIST of ContextRegistrationResponse. This ContextRegistrationResponse is similar to the ContextEntityResponse, but contains a ContextRegistration with a StatusCode. And here comes the problem:

-       The ContextRegistration contains a set of EntityIds and Attributes. How do we order the response by?

-       i.e.  DiscoverContextAvailabilityResponse contains 0..n ContextRegistrationResponse contains 0..m ContextRegistration. But we gave one homogenious list of EntityIDs. How to order them?

                Each ContextRegistrationResponse contains exactly one ContextRegistration. And in this ContextRegistration there is information about a certain ProvidinApplication who can provide the context information expressed in the list of EntityIDs and ContextRegistrationAttributes.

I do not see why the ordering should be important, as in the response it is explicit which ProvidingApplication has information about which Entities/Attributes.

Best,

Dénes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120423/9bbc1b82/attachment.html>