yumaworks-yangmap

Organization:

YumaWorks, Inc.

Module:

yumaworks-yangmap

Version:

2018-01-04

File:

yumaworks-yangmap.yang

Abstract:

YANG model mapping control block parameters. +--------------+ +---------+ +--------------+ | source model | <-> | yan...

Contact:

Support <support at yumaworks.com>

Check for an additional details:

YANG Catalog

Description:

YANG model mapping control block parameters.

+--------------+ +---------+ +--------------+
| source model | <-> | yangmap | <-> | target model |
+--------------+ +---------+ +--------------+

Purpose:
This module is used as metadata to convert
data instances from a source data model to
a target data model.
- present simplified model for CLI
- support a new module with objects that can
map to existing objects.

The structure of this metadata allows 1:N model mapping
of container and list data nodes.

Child nodes of containers and lists can be mapped to
multiple target nodes in the target model.

Terms:
source model: The data model that is visible to the
yangcli user in config term mode. This model is for
client use and does not exist on the server.

target model: The data model that is implemented on the
server. This model is not visible to the client in
config term mode.

yangmap: a set of mappings to convert a source schema
node to a target schema node. A source data node can
be mapped to multiple target nodes.

key stack: Each data node can be identified by its
absolute schema-node-identifier string and a set of
key values called the 'key stack'. The stack is comprised
of all key leafs from top to bottom and left to right.

ancestor keys: There are zero or more keys within a
a key stack that represent keys from ancestor nodes.
These values are fixed for the purposes of retrieval
operations.

local keys: There are zero or more keys within a
a key stack that represent keys from the current node.
This is only possible if the current node is a YANG list
and there is a key statement defined for that list.
These values are not fixed for the purposes of retrieval
operations.

Usage Restrictions:
Each yangmap must represent the model mapping for at
least one subtree.

Multiple subtrees can be represented in a single yangmap.

The source and terget subtrees must be completely disjoint.

Only top-level containers and lists used as nodemap
source objects are supported at this time.
An entire source data subtree from top to bottom
must be mapped.

Top-level choice-stmts are not supported.
The target node does not have to be a top-level data node,
but it must be a container or list node.

Containers and even lists can be removed from the source
hierarchy. There can be different containers and lists
in the target source tree.

Only configuration data nodes are supported at this time.
Operational data, RPC, action, notification are not yet
supported.

Only containers and lists can be mapped as source or target
nodes within a nodemap. Other nodes are allowed within the
nodemap within a keymap or childmap.

Only one mapping is supported per node.

Key mappings must be complete so that any node within
the source subtree can be mapped to its target node
without any missing key leaf values.

If a list is mapped to a container, then only one instance
of the list will be allowed.

Leafs should map to other leafs or leaf-list using the
same data type. Data type conversions will be attempted
if not.

If a leaf-list is mapped to a leaf then only once instace
is allowed in the leaf-list.

Copyright (c) 2018 YumaWorks, Inc. All rights reserved.

Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the BSD 3-Clause License
http://opensource.org/licenses/BSD-3-Clause