XML-SMI Mappings :: Muonics, Inc.

Home > Support > Documentation > XML-SMI Schema

This area is devoted to information regarding current efforts to move forward with an XML Schema for the purposes of mapping SMI (and possibly ASN.1 in general) to XML. Here you can find earlier proposals, the current schema version being developed and promoted by Muonics with the involvement of others in the SNMP community. This schema is supported in MIB Smithy, which was used to generate the examples below, as well as some third-party tools. MIB Smithy Professional supports lossless conversion between XML and SMI formats in both directions.

Current Version

XML-SMI-2.1.xsd - Update to add COPS-PR-SPPI support.
XML-SMI-2.0.xsd - Previous version of the Muonics/M. Kirkham XML-SMI Schema.

Samples

Past Draft Proposals

draft-irtf-nmrg-smi-xml-00.txt - Original DTD-based proposal by J. Schoenwaelder and F. Strauss.
draft-irtf-nmrg-smi-xml-01.txt - F. Strauss's conversion of the above 00 version to XML Schema.
XML-SMI-XSD.xsd - M. Kirkham's alternate conversion of the above 00 version to XML Schema.

SMIXML Mailing List

XML-SMI-2.0 Mapping Goals

The following were among the goals used in developing XML-SMI-2.0.xsd (listed in decreasing priority). Most have been met; some of the items that are less applicable to MIB modules (e.g. generic ASN.1 mappings -- macros and the like) have been partially addressed but could still use improvements in a future revision.

Filling in the holes where the old DTD is obviously broken or lacking (e.g. multiple-module support, adding AGENT-CAPABILITIES support, etc).
Ability to convert both MIB modules and SMI base/SNMP protocol modules from ASN.1 to XML and back again without any information loss. Some repositioning of ASN.1 comments is OK, as long as they are preserved (e.g. with the whole record they are associated with, or enumerations; comments placed arbitrarily between macro elements like the DESCRIPTION keyword and the quoted text that follows are recommended against anyway, so it's not necessary that every single element have a "comments" property).
Agreement on formats for things like revision timestamps, access/status keywords (I believe at least the keywords should be the same as in the SMI to simplify conversion).
Ability to convert from XML to other arbitrary formats (including code generation) via XSLT fairly easily.
Forward-compatibility with SMIng. If it's necessary later to, for example, loosen pattern restrictions or add elements/attributes to support SMIng, that's probably ok. Having to completely alter structures in an incompatible way should be avoided if possible.
A basic level of pattern rules so that various values can be thrown out by a validating XML parser as being obviously not of the expected type. Typical patterns that would be expected in a lexer to produce tokens of the given type (e.g. one or more numbers alone does not make an identifier). Strict checking of things like identifier lengths can be left to post-processor implementations outside of XML support (e.g. as long as a sequence of characters is a valid identifier in ASN.1 it should be valid in XML; checking for the SMI-imposed length limit is something best left to the SMI validation stage where it's important, and when just converting between formats like XML-to-HTML or XML-to-PDF etc. it isn't important).
Minimizing information redundancy (e.g. the change made to the imports so that the imported module name is listed only once, rather than once for each symbol imported).
For the benefit of existing implementations of the old DTD, the schema shouldn't pose great difficulty in updating existing tools to use it.
Obtaining a decent balance of "container" elements such as <assignments>, <typedefs>, <compliances>, etc. for both XSLT transforms to formats where only a subset of information is of interest (for example, maybe a transform that only generates a summary of relationships between different modules) and applications that might want to use the XML files directly to build internal data structures as they would loading or compiling a MIB that's in ASN.1. I'm still undecided whether or not I like the old DTD's structure that puts <node>s under <node>s and such, simulating the OID tree in the XML structure, versus following a more flat model the way macro invocations and other value assignments appear within an ASN.1 module. Both ways seem to have their benefits.