[Fiware-ngsi] NGSI-10 binding

[Tobias Jacobs]

Dear Fabian,

First of all, sorry for the extremely late reply.


1)      I think URIs inside URIs could be encoded as shown here http://www.w3schools.com/tags/ref_urlencode.asp. Does this sound reasonable?

2)      The xsd is the right version. Actually the ContextAttributeResponse as shown in Section 4 of the binding document was correct, but for some reason a wrong version made it into Section 3.3.1.1.
Thanks for pointing out, I corrected it in the document.
Best
Tobias

From: Tschirschnitz, Fabian [mailto:fabian.tschirschnitz at sap.com]
Sent: Mittwoch, 2. Mai 2012 18:21
To: Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] NGSI-10 binding

Dear Fiware-NGSI-list,

while implementing a test-suite for the NGSI10-Rest-Interface we stumbled about 2 issues so far:


1.       As Tobias mentioned in his 3rd question in his mail from March, 26th it could be a problem to encode an URI inside another URI. In RFC 3986 we found no proper way to solve this problem. As an example take part 3.7 of the NGSI10-Binding document v.0.98: Here the route http://{serverRooot}/{apiVersion}/contextEnitityTypes/{typeName}/attributes<http://%7bserverRooot%7d/%7bapiVersion%7d/contextEnitityTypes/%7btypeName%7d/attributes> is described. If you substitute {typeName} with http://www.sap.com/entityTypes/attributes/rooms the URI to fetch all attributes of all matching entities would be http://{serverRooot}/{apiVersion}/contextEnitityTypes/http://www.sap.com/entityTypes/attributes/rooms/attributes. And if you substitute the path of route 3.6 you get http://{serverRooot}/{apiVersion}/contextEnitityTypes/http://www.sap.com/entityTypes/attributes/rooms which would match the route 3.8 accidently. So in general we think it is necessary  to encode that typeName, e.g. in Base64.

2.       As defined in the NGSI10-Binding document 3.3.1.1 the contextAttributeResponse should consist of an optional ContextAttributeList, which is an Array of ContextAttributes, and a StatusCode. But in the Ngsi10_Operations_v07.xsd a ContextAttributeResponse is declared as such:

                        i.   <xs:complexType name="ContextAttributeResponse">

                       ii.       <xs:sequence>

                     iii.         <xs:element name="contextAttribute" type="data:ContextAttribute" minOccurs="1" maxOccurs="1"/>

                       iv.         <xs:element name="statusCode" type="data:StatusCode" minOccurs="1" maxOccurs="1"/>

                        v.       </xs:sequence>

                                                           vi.        </xs:complexType>
Which version is the right one?

Thank your for your time, Fabian.

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]<mailto:[mailto:fiware-ngsi-bounces at lists.fi-ware.eu]> On Behalf Of Tobias Jacobs
Sent: Montag, 26. März 2012 15:58
To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI-10 binding

Dear members of the FI-WARE NGSI-list

A new version of the NGSI-10 binding can be found at
https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi10-RestfulBinding-Draft.docx
Major changes are marked in red.

I am listing below the open questions I have identified, together with a proposal of how to solve them:


1)      (already postet last week) Do we allow PUT and DELETE on ../ContextEntities/{EntityID}, ../ContextEntities/{EntityID}/attributes and ../ContextEntities/{EntityID}/attributes/{attributeName}?

--> my proposal: allow only DELETE on these resources.

2)      When querying ../ContextEntities/{EntityID}/AttributeDomains with GET, does that also return the values of attributes that do not belong to any domain?
--> my proposal: yes



3)      Is there a standard way to encode a URI inside a URI? This is because {typeName} has the type xs:anyURI in NGSI. Google uses some encoding for in the links contained in their search results, but I do not know if that is a standard way, and where such a standard is described.



è My proposal: no proposal.

4)      When querying a../ {typeName} resource or a subresource of it, should each returned Entity also contain information on its type? This would be redundant information.

--> my proposal: include the type information (but this is more a feeling than a proposal)



5)      It is thinkable that multiple providers provide domain metadata of a certain attribute domain, but there is no concept of different value instances for metadata.

--> my proposal: no proposal yet



6)      Should we distinguish between datastructures and input/output messages in the RESTful binding?



è My proposal: do not distinguish; in the end it is all an xml datastructure. And also in the case of some convenient functions we sometimes return a datastructure instead of an extra output message.


Thanks for your consideration and best regards
Tobias

From: Tobias Jacobs
Sent: Freitag, 23. März 2012 17:10
To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: NGSI-10 binding

Dear all,

Sorry, I have to admit that I will not manage to complete the new binding document version by today as promised.

The current version (which also includes comments about open points) can be found at https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi10-RestfulBinding-Draft.docx

Please feel free to have a look at it and comment.

Best regards
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120509/e21717b0/attachment.html>