Schema Directory Registration Interface

In order to perform a Register request to register a data model schema (or a list of data model schemas), a node issues a POST method to the registration interface. This POST method must contain the list of schema link register entries of the data model schema to be registered.

Each schema link register must include the globally unique identifier required by the schema repository and, optionally, an anchor attribute (as explained in the CoAP Resource Directory

specification [SKB+18], section “5.3.Registration”) in order to indicate schemas stored outside

the origin node. Theuid attribute is used to specify the globally unique identifier of a schema

link register. Although it is not mandatory, it is recommended that theuid attribute follows the

URI format. There is no upper bound to the length of theuid attribute. Although it would be

recommended to set a maximum length limit, unique identifiers will be probably mapped to namespaces used in the schemas (XML and JSON namespaces), which are known to be verbose.

On successful registration, the schema repository creates a new registration resource in the schema directory for each unique identifier not already registered. Therefore, for each new data

model schema (i.e.,uids not already registered in the schema directory) contained in the schema

link register list, a new resource is created and a new schemaId is generated and assigned to the data model schema. In case a data model schema with the same unique identifier has already been registered, the schema repository reuses the already assigned schemaId. Due to security reasons, some checking may be necessary in order to ensure that the unique identifier and links really identify and point to the same data model schemas.

Once the schema repository finishes the internal registration process (i.e., resource creation and schemaId assignment), it returns the location of the registration resource to the origin node. The location is included in the “Location” header of the response sent by the schema repository.

As in the resource directory, a node that just registered its data model schemas, should remember the location of the registration resource. This location is used in management operations such as the refreshing of the registration lifetime as well as inspect, update or remove the resource.

Schema registrations must be refreshed within a given period. This period can be specified in

the registration request using thelifetime parameter. If a lifetime parameter is not specified,

a default value is assigned. Lifetime values are assigned to the whole registration resource. If the lifetime of a registration resource expires, all the links registered by the origin node are removed from the schema directory. If all the links of a given unique identifier (and hence, of a data model schema) are removed, the schema registration resource is deleted and the schemaId is freed.

The registration request may also include acontext parameter that will be applied to all the

schema link registers contained in the request. However, if a schema link register already has an anchor attribute, the context parameter is ignored. The purpose of the context parameter is

to reduce the size of each schema link register. If thecontext parameter is not included, it is

assumed that the origin node is the context. Nevertheless, links that upon registration did not

contain ananchor attribute, which indicates that the data model schema is stored outside the

origin node, are assigned an anchor equal to the context URI of the registration.

The registration request interface of the schema directory is an adaptation of the registration

interface specified for the resource directory (specified in [SKB+18], Section 5.3).

Interaction: CoAP Endpoint -> Schema Directory Method: POST

URI Template: +sd?lt,con

The parameterslt and con are specified as defined in [SKB+18], i.e, they respectively indicate

the lifetime of the registration in seconds and the default base URI for the request’ schema link register entries.

Following with the example shown in Figure 5.5, Figure 5.6 shows an example of a request sent and a response received by a node registering two data model schemas using the registration interface path “/sd”. The node attempts to register two data model schemas with unique identifier values of “example:uri:schema1” and “example:uri:schema2”. For the data model schema identified as “example:uri:schema1”, two links are provided, one located in the node itself (on the path “/sch/schema1”) and the other in an external server in the URL “http: //example.com//schema1/schema”. For the data model schema identified as “example:uri: schema2” one single link located at the node in the path “/sch/schema2” is provided. The content format for all the links is “application/xml” (‘41’ in CoAP identifier code format). The size and hash parameters are provided in order to verify the schema document.

Upon registration, the schema repository will, optionally, download the schema, store it locally and make it available through a CoAP resource interface. In this case, the schema repository adds the link to the schema directory so it is available on the lookups interfaces.

Section 5.3. CoAP Binding 89

 

Req: POST coap://sd.example.com/sd Content−Format: 40

Payload:

</sch/schema1>;ct=41;rt="schema";uid=example:uri:schema1;sz=512;hash="0123456789←- abcdef0123456789abcdef",

</schema1/schema>;ct=41;rt="schema";uid=example:uri:schema1;anchor="http://example.com";sz←-

=512;hash="0123456789abcdef0123456789abcdef",

</sch/schema2>;ct=41;rt="schema";uid=example:uri:schema2;sz=322;hash="←- abcdef0123456789abcdef0123456789"

Res: 2.01 Created Location: /sd/1245

 

Figure 5.6: Example registration request on a schema directory.