DMG logo PMML 4.3 - PMML Conformance
PMML4.3 Menu

Home

Changes

XML Schema

Conformance

Interoperability

General Structure

Field Scope

Header

Data
Dictionary


Mining
Schema


Transformations

Statistics

Taxomony

Targets

Output

Functions

Built-in Functions

Model Verification

Model Explanation

Multiple Models

Association Rules

Baseline Models

Bayesian Network

Cluster
Models


Gaussian
Process


General
Regression


k-Nearest
Neighbors


Naive
Bayes


Neural
Network


Regression

Ruleset

Scorecard

Sequences

Text Models

Time Series

Trees

Vector Machine

PMML 4.3 - PMML Conformance

PMML Document Validity

PMML is a standard for XML documents which express trained instances of analytic models. The following classes of model are addressed:

A valid PMML 4.3 document must be an XML document that is valid with respect to the reference XML Schema found at https://www.dmg.org/PMML4.3/pmml-4-3.xsd, after removing additional attributes that have a name with the prefix "x-". Additional elements with a name prefix "X-" can be defined in an internal Schema. A valid PMML 4.3 document must obey the restrictions expressed in the model specifications found at https://www.dmg.org/PMML4.3/.

The model specifications define various restrictions which are not implemented in the XML Schema. Examples are:

"The sequence of LinearNorm elements defines a sequence of points for a stepwise linear interpolation function."
(The order of these elements is critical but it is not possible to enforce this using the XSD.)

or

"In most cases Score is required but for model composition where a tree model is used to select a regression model, the regression equation will provide the Score and, in this case, Score is not required. In all other cases, if the winning node in the tree evaluation does not have a Score, the result is invalid."
(Ensuring that tree nodes in non-model composition models have the Score attribute is also not possible to enforce in the XSD.)

PMML Conformance

PMML intends to enable application portability, sharing and reuse of analytic models produced by a variety of tools. Conformance must therefore be specified from both producer and consumer perspectives. Applications need ways to specify what kinds of analytic models they can use, and modeling tools need ways to specify what kinds of analytic models they produce. A PMML document is what gets produced by a modeling tool to specify a trained analytic model and is what an application uses to deploy that model. Satisfying producer conformance rules ensures a model definition document is syntactically correct and in fact defines a model instance which is consistent with semantic criteria that are defined in model specifications. Satisfying consumer conformance rules ensures that such a model will be applied in ways which are valid.

Producer Conformance

A tool or application is producer conforming if it generates valid PMML documents for at least one type of model; a producer conformance statement must include which types of models are supported in this way. Producer conformance is a "contract" between a data mining tool/application vendor and users and application suppliers which states that the PMML documents defining models of those types it supplies can be integrated and used.

Consumer Conformance

An application is consumer conforming if it will accept valid PMML documents for at least one type of model. A consumer conformance statement must indicate which types of models are accepted. Application conformance is a "contract" between the application suppliers and both users and data mining tool/application vendors which states that PMML documents defining models of those types can be integrated and used. An essential example is that if an application is consumer conforming for Polynomial-Regression-model types, then valid PMML documents defining models of this type produced by different producers would be interchangeable in the application.

Deprecation

As the standard matures, the committee occasionally decides to replace certain aspects (e.g. elements and/or attributes) in the specification with new alternatives that typically have a wider application. In order to ensure a smooth and timely transition for both PMML producers and consumers, aspects of the standard to be replaced are first marked as deprecated before they are completely removed. The intention is to initially discourage the use of the old aspects before actually prohibiting it.

Deprecated aspects of the standard must be clearly documented as such in the corresponding sections(s). In addition to what is exactly deprecated, the text should provide enough information and/or references about the alternative way(s) of achieving the same functionality.

Through deprecation, PMML producers are discouraged from generating the old aspects and should plan on migrating to the new alternatives when generating newer versions of PMML documents. However, the deprecated aspects remain valid until they are removed in a later release. PMML consumers should support the deprecated aspects for as long as they are part of the standard, along with the new alternatives.

In general, deprecated aspects will be completely removed in the following major release of the standard, but never earlier than 12 months after the deprecation release. For example, an aspect that gets deprecated in release 4.1 will remain deprecated and valid for releases 4.2, 4.3, etc. It will be removed at the 5.0 release, assuming that the 5.0 release happens more than 12 months after the 4.1 release. In certain cases, DMG may decide to extend the life of certain deprecated aspects beyond the following major release.

e-mail info at dmg.org