выражения пути yang для ссылки на узлы данных и узлы схемы и т. д.

рассмотрим следующий модуль ян

module mod {
    yang-version 1;
    namespace "http://example.com/mod";
    prefix m;
    revision "2016-09-09" {
       description "Initial revision.";
    }
    container foo {
        description 'container foo';
        leaf l {
            type string;
        }
    }
}

Какое выражение пути верно для достижения листа l?

/mod:foo/l
/m:foo/l
/foo/l

Если в моем приложении активны 2 версии одного и того же модуля, как клиент может указать, какой узел версии его интересует?

и есть ли выражение пути для ссылки на «описание» листа l?


ietf-netmod-yang ietf-restconf
person user19937    schedule 18.09.2016    source источник
comment
Вы не указали контекст, в котором хотите сослаться на l. Листовой путь? Выражение XPath (должен, когда)? Выражение XPath в NETCONF get/get-config? Запрос RESTCONF?   -  person predi    schedule 19.09.2016
comment
I have 2 revisions of the same module active in my application. Сервер НЕ ДОЛЖЕН реализовывать более одной версии модуля, см. RFC. Обратите внимание, что в RFC6020 вы не найдете этого явного упоминания, но намерение было таким же.   -  person predi    schedule 19.09.2016
comment
Нет возможности напрямую обратиться к описанию какого-либо узла, так как в этом нет необходимости. Можете ли вы объяснить свой вариант использования для этого более подробно?   -  person predi    schedule 19.09.2016
comment
1. выражение пути, которое я ищу, является целевым URL-адресом в GET, например. Какое из этих 3-х выражений верно?   -  person user19937    schedule 19.09.2016
comment
мой вариант использования для «описания» примерно такой. Клиент отправляет модуль yang на сервер. Клиент хочет убедиться, что сервер правильно видит структуру. Клиент говорит: покажите мне описание этого листа или что такое лист по умолчанию и т. д. Я думаю, это должно быть просто обычное выражение xpath относительно файла yin. серверу просто нужно обработать выражение так, как ему нужно.   -  person user19937    schedule 19.09.2016

Ответы (1)


arrow_upward
1
arrow_downward

Какое выражение пути верно для достижения листа l?

В контексте RESTCONF GET схема, описанная в draft-ietf-netconf-restconf-16, Раздел 3.5.3, Кодирование идентификаторов ресурсов данных в URI запроса.

Идентификатор ресурса данных RESTCONF кодируется слева направо, начиная с узла данных верхнего уровня, в соответствии с правилом «api-path» в разделе 3.5.3.1. Имя узла каждого предка узла целевого ресурса кодируется по порядку, заканчиваясь именем узла для целевого ресурса. Если узел в пути определен в другом модуле, а не в его родительском узле, или его родителем является хранилище данных, то имя модуля, за которым следует символ двоеточия (":"), ДОЛЖНО быть добавлено к имени узла в идентификаторе ресурса. Подробности см. в разделе 3.5.3.1.

Поэтому правильный URI будет примерно таким:

/restconf/data/mod:foo/l

Если в моем приложении активны 2 версии одного и того же модуля, как клиент может указать, какой узел версии его интересует?

Вы не можете выразить такую ​​просьбу. Это одна из причин, по которой серверу разрешено реализовывать только одну версию модуля YANG. В YANG 1.1 это явно запрещено, а в YANG 1.0 это только подразумевается. Обратите внимание, что соответствующие реализованные модули YANG могут ссылаться (импортировать) на несколько версий одного и того же модуля, но только одна из них может быть объявлена ​​как реализованная (возможно, самая новая). Поскольку правила обновления модуля довольно строгие, определения не просто исчезнут в более новой версии модуля, поэтому клиенты в безопасности.

есть ли выражение пути, доступное для ссылки на «описание» листа l? мой вариант использования для «описания» примерно такой. Клиент отправляет модуль yang на сервер. Клиент хочет убедиться, что сервер правильно видит структуру. Клиент говорит: «Покажите мне описание этого листа» или «Какой лист по умолчанию» и т. д.

Вы, кажется, неправильно понимаете роль модели YANG. Клиент не управляет моделью сервера, он может управлять только данными, описанными в этой модели! Такое дело в домене сервера и его мейнтейнера.

Единственный стандартный способ запроса модели YANG (о которой я знаю), а не моделируемых ею данных, - это получить файл YANG/YIN с сервера (get-schema), а затем проанализировать его самостоятельно.

В качестве примечания. Клиент, который реализует ваш модуль и получает действительный ответ от сервера, по своей сути знает, какое описание соответствует какому элементу XML/объекту JSON, поскольку он уже выполнил «сопоставление» между документом экземпляра и моделью (схемой) во время проверки. фаза.

person predi    schedule 20.09.2016