Using DSDL plus annotations for Netconf (+) data modeling Rohan Mahy draft-mahy-canmod-dsdl-01

What is DSDL? DSDL = Document Schema Data Languages An ISO family of standards DSDL uses a modular approach to schema languages –Part 2 = Relax NG - traditional schema language: structure –Part 3 = Schematron - rule based validation –Part 4 = NVRL - validate parts of instance doc with different schemas/languages –Part 5 = DataType Library Language –etc … Annotations are encouraged as part of modularity My usage of “Data Model” –A model for describing the semantics and syntax of (configuration and operational) data. Does not include verbs.

Why Relax NG for syntax? Easy to read and learn (Compact or XML) Used by W3C (XHTML, SVG, XML Sig, RDF) Better XML support than XSD: –robust native support for XML namespaces –unifies elements and attributes –unordered content supported –describes which pattern is root element Convertible to XSD Patterns can be scoped to prevent conflicts from one module

Schematron - rule-based validation Rule-based validation based on XPath expressions. Supports reusable abstract patterns Validation can be split in phases based on context Implementer can use a Schematron validator or write their own native code to perform an equivalent validation check. <assert test="dhcp:default-lease-time <= dhcp:max-lease-time"> Default lease time cannot be larger than maximum lease time

Semantic Annotations Important annotations: –keys to uniquely identify elements in a list –define relational integrity constraints –insure data is relevant to operation containing it These annotations can be implemented in native code on device or converted to additional Schematron rules by XSLT

Extensibility Relax NG has a nice pattern-based extensibility mechanism –redefine patterns completely –combine by choice –combine by interleave Can include external grammars and keep scopes separate (ex: both dhcp.rnc and interfaces.rnc have an element-interface pattern) # config-root.rnc default namespace = " start = element-config element-config = element config { external "interfaces.rnc" ? & external "dhcp+extensions.rnc" ? } # dhcp+extensions.rnc include "dhcp.rnc" # base module include "dhcp-tz.rnc" # timezone extension include "dhcp-wins.rnc" # WINS server ext # dhcp-tz.rnc namespace tz = " element-dhcp-option &= element tz:timezone { token }?

Met nearly all requirements in RCDML draft Met ALL Netconf-specific requirements (Section 3.1) Some highlighted unique features –Compound keys / Deep keys –Implementation Defaults Most defaults are valid per version of the schema. –Formal validation w/ Schematron Can implement these rules via custom code from assert text, or automatically using a Schematron validator (free libraries in C++, Java, C and Python)

What’s nice about this approach Reuse of appropriate schema languages and tools is a good thing. Modular architecture makes incremental implementation/deployment and additional reuse easier (add other parts of DSDL, use subset of Netconf solution for another IETF protocol). Being able to add data model information for existing IETF schemas (LDAP-enabled directories, SIP phone config files, early Netconf users) is a good thing. Making Schematron available for formal machine-readable validation to clients that want it is a good thing.

Schema Plus vs. Model Plus approach Pure Semantics –UML / XMI –OWL (without a specific serialization) Semantics + some syntax (top down) –Yang –Kalua Schema + some semantics (bottom up) –DSDL + annotations –XSD + annotations

Semantics vs. Syntax dilemma Pure semantic approaches can represent things we cannot easily represent in Netconf or even in XML syntax –Many to many relationships (graph vs tree) Top down approaches can constrain legitimately good syntax and blur semantics: –element vs. attribute representation of terminal nodes –not distinguishing semantically ordered content (sequence) from unordered content (bags) Bottom up approaches are not easily convertible to radically different syntax (ex: CLI)

Upgrading schema to data model There are lots of XML-based schema in the wild (XSD and Relax NG). It seems very beneficial to be able to take an existing schema and turn it into a data model while maintaining backward syntax compatibility –Folks who defined XSD for use with Netconf. –Other IETF WGs that already defined syntax of their schema but want data modeling. –Other schemas defined elsewhere that we want to import for Netconf.