[Fiware-ngsi] AttributeDomainName problem

Haller, Stephan stephan.haller at sap.com
Mon Mar 19 12:36:43 CET 2012
Previous message: [Fiware-ngsi] AttributeDomainName problem
Next message: [Fiware-ngsi] AttributeDomainName problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Done.
-Stephan

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

Dear all,

There is a OLD copy in the version control under the following link:
https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi10-RestfulBinding-Draft.docx

Miguel wrote a mail some days ago that now everyone has full SVN access not just the administrators. It would be more useful if we used this SVN for updates instead of email attachments.

Stephan, can you please update this version with the one you just sent?

Best,
Dénes

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

Hi Martin,

Thank you for the effort. I agree that we can define the convenience functions to not deliver the full NGSI functionality, but that they work more "naturally". But this doesn't solve the main issue how to handle duplicate attribute names, meta data etc., does it? It only allows us to handle these situations in a way that is not 100% in line with the NGSI spec.

A few additional remarks:

1.       Might be a good idea to use different colours in the overview figure for the convenience functions.

2.       I think it would then also be a good idea to split the table in two: One for the convenience functions, and one for the others.

3.       A DELETE on an attribute should delete the whole attribute, not just the value.

4.       We also should have a function to append new attributes to a domain

5.       The overview has  resource "contextSubscription", while the table has one called "subscription". I guess this is the same...

6.       Please add SAP to the list of contributors.

I changed these 6 points, see attachment.

Regards,
-Stephan



From: Martin Bauer [mailto:Martin.Bauer at neclab.eu]
Sent: Freitag, 16. März 2012 18:08
To: Martin Bauer; Bisztray, Denes (NSN - HU/Budapest); Tobias Jacobs; Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: [Fiware-ngsi] AttributeDomainName problem

Dear NGSI enthusiasts,

I worked on the NGSI-binding and came to the conclusion that we should avoid mixing the general NGSI functionality
and the convenience operations. The main reason for this that the full NGSI functionality allows the specification
of scopes that restrict the operational space on which a given operation operates, e.g., geographical area, network
domain etc. The convenience operations will have to be implicitly scoped (e.g. global scope, single domain scope),
whereas in the NGSI operations an explicit scope can be given. Partially using scopes on the resources intended for
the convenience operations could lead to unexpected results and in some cases it is not clear whether scopes can
be applied even though NGSI allows that.

Furthermore, having a straightforward mapping between NGSI operations and respective REST resources is
an additional advantage.

In addition to that, I applied the discussed changes on the resources for the convenience operations.
In the current document only the sections 2.1 and 2.1.1 are updated. Once we reach agreement on those, the
updates to the remaining sections should be straightforward.

Have a nice weekend and talk to you on Monday or Tuesday.

Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Martin Bauer
Sent: Tuesday, March 13, 2012 2:43 PM
To: Bisztray, Denes (NSN - HU/Budapest); Tobias Jacobs; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: Re: [Fiware-ngsi] AttributeDomainName problem

Hi all,

Okay, I'll wait if there is some further feedback and if there is no opposition, I'll update the document
in two days.

Possibly NEC will also provide a first binding proposal for NGSI-9.

Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]<mailto:[mailto:denes.bisztray at nsn.com]>
Sent: Tuesday, March 13, 2012 12:48 PM
To: Martin Bauer; Tobias Jacobs; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Martin, all,

I agree with this setup, if there are no criticism in 2 days, please update the doc. We give you Admin privileges so you can upload it to SVN.

For the GET on:
//{serverRoot}/NGSI10/contextEntities/{EntityId}
I would vote it to be the same as the GET on:
//{serverRoot}/NGSI10/contextEntities/{EntityId}/attributeNames/

I would like to add some things to this.


1.      AttributeID convenience method
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeNames]/{attributeName}
As mentioned this possibly returns multiple ContextAttributes (according to the queryContextAttributeResponse). I propose another convenience GET on:
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeNames]/{attributeName}/{attributeID}
This return a queryContextAttributeResponse as well, giving back a single item.


2.      Other HTTP primitives
I'd support the following primitives as well above or instead of the ones described in [REST-Binding-NGSI10].

POST on
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeNames]/{attributeName}
Adds new instances of the attribute.

PUT on
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeNames]/{attributeName}/{attributeID}
Replaces that specific instance

DELETE on
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeNames]/{attributeName}/{attributeID}
Deletes the specific instance








From: ext Martin Bauer [mailto:Martin.Bauer at neclab.eu]<mailto:[mailto:Martin.Bauer at neclab.eu]>
Sent: Tuesday, March 13, 2012 12:16 PM
To: Bisztray, Denes (NSN - HU/Budapest); Tobias Jacobs; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes, all,

Sorry that it took a bit longer, but I had to look at the respective documents first.

So if we agree that a ContextElement is only a container for information pertaining to a (logical) ContextEntity,
we should adapt our NGSI-10 Resource Tree to reflect this (orange colour shows name changes, brown colour potential additions):

//{serverRoot}/NGSI10/contextEntities/{EntityId}
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeNames]/{attributeName}
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeDomainNames]/{attributeDomainName}

//{serverRoot}/NGSI10/contextEntityTypes/{typeName}[/attributeNames]/{attributeName}
//{serverRoot}/NGSI10/contextEntityTypes/{typeName}[/attributeDomainNames]/{attributeDomainName}

In the following I only look at doing a GET on the respective resources. If we agree on that, I would try to update the complete document accordingly.

A GET on
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeNames]/{attributeName}
should return a queryContextAttributeResponse as defined in [REST-Binding-NGSI10]

A GET on
//{serverRoot}/NGSI10/contextEntities/{EntityId}[/attributeDomainNames]/{attributeDomainName}
should return a ContextElementResponse ([NGSI10 Specification], Section 5.5.15), which includes a single ContextElement.
As all context attributes included belong to the requested attribute domain, this would fit.

A GET on
//{serverRoot}/NGSI10/contextEntities/{EntityId}/attributeNames/
should return a ContextElementResponse ([NGSI10 Specification], Section 5.5.15), which includes a single ContextElement
with all ContextAttributes, but without any attributeDomain

A GET on
//{serverRoot}/NGSI10/contextEntities/{EntityId}/attributeDomainNames
should return a queryContextResponse ([NGSI10 Specification], Section 5.4.1.2) with a list of ContextElementResponses, where preferably the ContextElement in each ContextElementResponse groups the ContextAttributes of one attributeDomain

A GET on
//{serverRoot}/NGSI10/contextEntities/{EntityId}
could be synonymous to one of the former, to be decided

The type-Resources all return queryContextResponses. The content should fit the structure above, i.e. when asking directly for attributeNames, only ContextAttrbitutes should be contained, when asking for attributeDomainNames, the attributeDomain structure should be reflected.

[REST-Binding-NGSI10] NGSI-10 Context Management, RESTful binding, Draft Document v0.9
[NGSI10 Specification] NGSI Context Management, Candidate Version 1.0, OMA 2010


Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Monday, March 12, 2012 7:26 AM
To: Martin Bauer; Tobias Jacobs; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Martin, all,

Thanks for confirming I understand correctly your position. Now comes the next phase: how do we map this to the NGSI, and to REST?

Currently the facts according to the NGSI-10 spec are:


1.      you can have 1 attribute domain within a context entity

2.      the context entity's ID is the EntityID name and if the name is not unique the type.

3.      The restful binding uses only the name from this

I'd like ask propositions, how to have:


a)      Have multiple context elements in restful binding with respect to point 3.

b)      Distinguish the different context entities if the type is the same (like in your slide)

Best,
Dénes

From: ext Martin Bauer [mailto:Martin.Bauer at neclab.eu]<mailto:[mailto:Martin.Bauer at neclab.eu]>
Sent: Friday, March 09, 2012 3:16 PM
To: Bisztray, Denes (NSN - HU/Budapest); Tobias Jacobs; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes, all,

I made two slides, one showing the logical structure of an entity and the second showing how context elements represent (partial) views of the entity. I hope this helps in understanding the relationships.

Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Friday, March 09, 2012 1:54 PM
To: Martin Bauer; Tobias Jacobs; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Martin, Tobias,

Ok, let me sum up what we have (to be sure that I understand correctly):

-          An Entity is NOT a ContextElement

-          An Entity can be one or many ContextElement

-          The connection between an Entity and its ContextElements is not defined

-          A ContextElement has one AttributeDomain

Is that correct?
If it is, I really don't get why we talk about attributeDomainS in the RESTful binding such as:
.../ContextElements/device1/AttributeDomains/device_info

There is one attributeDomain.
Can someone have any idea how to express the connection between an Entity and its ContextElements?

Best,
Dénes


From: ext Martin Bauer [mailto:Martin.Bauer at neclab.eu]<mailto:[mailto:Martin.Bauer at neclab.eu]>
Sent: Friday, March 09, 2012 1:46 PM
To: Tobias Jacobs; Bisztray, Denes (NSN - HU/Budapest); ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes,

Tobias is right. ContextElement is a container for entity-related information. Such a container can contain at most one AttributeDomain. If it does, all attributes have to belong to that AttributeDomain. Nevertheless one Entity may have context attributes in multiple AttributeDomains, which then have to be represented in multiple containers.

If we want to make the difference between ContextAttributes and AttributeDomains more explicit, we have to
put different sub-resources, e.g.

.../ContextElements/device1/AttributeDomains/device_info
and
.../ContextElements/device1/ContextAttributes/deviceStatus


Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

From: Tobias Jacobs
Sent: Thursday, March 08, 2012 11:39 AM
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes,

The connection in my view is is that a ContextElement contains some information about Entities, but not necessarily all available information. For example, if a ContextElement appears inside a queryContextResponse, it contains only the attributes that have been queried in the queryContextRequest.

I will be traveling for the rest of the day and will be back to the discussion tomorrow.

Best
tobias

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

Hi Tobias,

I'm confused then.

-          What is the connection between an "Entity" and a ContextElement datastructure? I assumed 1:1 connection

-          If it is an 1:n connection, how should we express it?

-          Is it supported by the standard? Page 24, sec 5.5.5 - EntityId/Type says: If EntityId uniqueness is only guaranteed in combination with Type, then Type SHALL be present.  - I understand this as only an option, not a recommendation.

Best,
Dénes

From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]<mailto:[mailto:Tobias.Jacobs at neclab.eu]>
Sent: Thursday, March 08, 2012 9:51 AM
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes,

To my understanding, only one attributeDomain can be expressed in the ContextElement Datastructure, but still one Entity can have attributes from several domains.

Best
Tobias


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

Hi Tobias,

The missing point is that you can have one attribute domain per entity. So the .../contextElements/device1/only_domain essentially is the same as .../contextElements/device1

Best,
Dénes

From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]<mailto:[mailto:Tobias.Jacobs at neclab.eu]>
Sent: Thursday, March 08, 2012 9:24 AM
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; ext Haller, Stephan; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>
Subject: RE: AttributeDomainName problem

Hi Denes, all,

Sorry if I have missed some points in previous discussions, but I still do not see why the existing resource structure should not be suitable for querying all attributes of a domain.
Let assume that we have an entity "device1" and two attribute domains "device_info" and "vendor_info". Querying these domains would  translate into GET operations to the resource
.../ContextElements/device1/device_info
and
.../ContextElements/device1/vendor_info,
respectively.

Best
Tobias



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

Hi Martin, Stephan, all,

Thanks for the insight. I completely understand that it would be good to query attributes via attribute domains. However, the RESTful binding in its current form makes it similar to querying a context element. Can you recommend where should we move the attributedomain queries? Maybe creating another root resource /attributeDomains in line with /contextElementTypes ?

Best,
Dénes

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

Dénes, Stephan, all,

The primary idea of an attribute domain is that you can group context attributes with it and query / update
the whole group.

Context attributes can live without an attribute domain, i.e. there is no fixed structure relation enforced.
This means that in principle the same context attribute could be part of multiple attribute domains, it is
just a grouping after all. Whether you model it in such a way or whether context attributes in practice belong
to at most one / exactly one attribute domain is up to the one designing the concrete model / the one
implementing the system. NGSI itself keeps these options open.

However, as was rightly pointed out, the structure of a ContextElement allows to specify at most one
attribute domain and if it is present all context attributes belong to that attribute domain.
An Entity with context attributes belonging to multiple specified attribute domains therefore would have to
be represented by multiple ContextElements.

Regarding the REST binding, it should ideally be possible to query an attribute domain as you want to
get the whole set of context attributes grouped under this attribute domain.

Best regards,

Martin

------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu<mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu<http://www.nw.neclab.eu/>

*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

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

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]<mailto:[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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: ext Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: ext Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: ext Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto:fiware-ngsi at lists.fi-ware.eu>
Cc: Haller, Stephan; ext Martin Bauer; laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>; laurence1.dupont at orange.com<mailto: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<mailto: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/20120319/95d673f7/attachment.html>
Previous message: [Fiware-ngsi] AttributeDomainName problem
Next message: [Fiware-ngsi] AttributeDomainName problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Fiware-ngsi mailing list
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy