[Fiware-ngsi] AttributeDomainName problem

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

Stephan, all,

 

There are two directions where this conversation need to go:

 

1.       How to handle updates with different AttributeDomain.

 

I agree with your table. That is a reasonable assumption. About the question marked elements:

-          When not present and the request contains AttributeDomainName, I'd update it to the new one.

-          When present, and the request does not contain anything, I'd leave it. No change intention.

 

However, I'm not sure if present and the request also contains, we should make it fail. After all it is an ContextElementUpdate operation which should be able to update the context element, including its properties. If an update call with different AttributeDomain fails, then the AttributeDomainName is not changeable. 

 

Is the always set policy too aggressive? I.e. if AttributeDomainName is present in request, then it will be updated, if not, the one present will remain?

 

2.       How to change the RESTful binding

 

I would simply remove the AttributeDomain resource inside ContextElementId and ContextType. And that's it. 

 

Best,

Dénes

 

 

From: ext Haller, Stephan [mailto:stephan.haller at sap.com] 
Sent: Wednesday, March 07, 2012 11:12 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,

 

Yes, you are right - my oversight. The table in 5.5.1 clearly says that the AttributeDomainName is part of the ContextElement structure - hence, a ContextElement cannot have attributes from several domains.

 

The consequence on this is that if someone tries to update a ContextElement with a different AttributeDomainName, that call MUST fail. Less clear is what should happen when no AttributeDomainName has been specified:

 

Existing ContextElement

ContextElement in Update request

No AttributeDomainName

AttributeDomainName included

No AttributeDomainName

OK

Update and set attribute name?

AttributeDomainName set

Update?

OK if same name

 

 

 

Regards,

-Stephan

 

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com] 
Sent: Mittwoch, 7. März 2012 10:52
To: Haller, Stephan; 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

 

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/6438b1bb/attachment.html>