[Fiware-ngsi] AttributeDomainName problem

[Bisztray, Denes (NSN - HU/Budapest)]

Hi Stephan, all,

 

Let me show the other side of the problem. If we look at the context query procedure, we realize that the queryContextResponse contains in the end a list of ContextElement structures. As I pointed out previously, one ContextElement can have one AttributeDomain. 

 

So the update possibility Stephan pointed out is another problem. Subsequential updateContextRequests can have different domains on the same ContextElement. However, when queried by queryContextResponse, which AttributeDomain to give?

 

I don't want to restrict NGSI, but these facts point to the previous conclusion that one ContextEntity can have one AttributeDomain. The consequences definitely do simplify things, but that is unintentional.

 

Best,

Dénes

 

 

From: ext Haller, Stephan [mailto:stephan.haller at sap.com] 
Sent: Wednesday, March 07, 2012 10:18 AM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu
Cc: ext Martin Bauer; laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem

 

Dénes, all,

 

I think this again points to a weakness of the NGSI spec. The lack of distinction between Attribute and AttributeDomain.  Also in Figure 2, AttributeDomains are not mentioned. 

 

Anyway, I read the spec as follows: In one single update operation, all attributes have to belong to the same domain (or none at all). However, in two consecutive updates on the same context element, you could add first attributes of domain 1 and in a second call then the attributes for domain 2.

 

But it certainly would simplify things if we would mandate that all attributes of a context element belong to the same domain. If an entity has attributes from several domains, then several context elements need to be created.

 

My main question is if we really need to make further restrictions on the standard spec. While I believe the resulting solution would be cleaner and simpler, I don't want to define anything non-compliant without a real need.

 

Regards,

-Stephan

 

 

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com] 
Sent: Mittwoch, 7. März 2012 08:27
To: fiware-ngsi at lists.fi-ware.eu
Cc: Haller, Stephan; ext Martin Bauer; laurent.artusio at orange.com; laurence1.dupont at orange.com; Tobias Jacobs
Subject: RE: AttributeDomainName problem

 

A week has passed and got no reply to this mail. 

In case there is no reply in 2 days, I assume that that the attributeDomainName is indeed an entity level property, and as such is not relevant for special address in the RESTful binding. Neither in the contextElementId nor the contextElementType resource. 

Best,

Dénes

_____________________________________________
From: Bisztray, Denes (NSN - HU/Budapest)
Sent: Thursday, March 01, 2012 1:06 PM
To: fiware-ngsi at lists.fi-ware.eu
Subject: AttributeDomainName problem

Hi All,

Sorry for bringing up yet another topic, but I realised that the RESTful binding of the AttributeDomainName is a bit questionable.

The spec says (sec 5.5.1, pg 22):

AttributeDomainName (xsd:string) - Name of the attribute domain that logically groups together set of Context Information attributes. Examples of attribute domain are: device info (battery level, screen size, ...), location info (position, civil address, ...).

And below that at the ContextAttribute it says:

ContextAttribute [0..unbounded] - List of Context Information attributes. Note: In case of the attributeDomainName is specified all

contextAttribute have to belong to the same attributeDomainName.

So as it seems inside a ContextElement you have only one attributeDomain. 

However, the restful binding puts in inside:

/contextElements/{contextElementID}/{attributeDomainName}

And says: Retrieve the values of all attributes of the context element belonging to the specific domain

This seems to be a conflict to me. ( i.e. if that attributeDomainName is queried that is specified in the ContextElement then all attributes are returned otherwise none?).

What if we move this one direction higher? i.e.

/contextElements/{contextElementId}

/contextAttributeDomains/{attributeDomainName}

(not in the same level of {contextElementId} to avoid the resolution chaos)

Best,

Dénes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120307/7e991e34/attachment.html>