The primary mechanism for extending MSML is the "package". A package is an integrated set of one or more XML schemas that define
additional features and functions via new or extended use of elements and attributes. Each package, except for those defined in the
current document, is defined in a separate standards document, e.g., an Internet Draft or an RFC. All packages that extend the base MSML functionality MUST include references to the MSML base set of schemas provided in the Internet Drafts. A schema in a package MUST only extend MSML; that is, it must not alter the existing specification.
A particular MSML script will include references to all the schemas defining the packages whose elements and attributes it makes use of.
A particular script MUST reference MSML base and optionally extension package(s). See the IANA Considerations section.
Each package MUST define its own namespace so that elements or
attributes with the same name in different packages do not conflict.
A script using a particular element or attribute MUST prefix the namespace name on that element or attribute’s name if it is defined in a package (as opposed to being defined in the base).
MSML consists of a core package that provides structure without support for any specific feature set. Additional packages, relying on the core package, provide functional features. Any combination of additional packages may be used along with the core package. The following describes the set of MSML packages defined in this document.
+---+
| MSML Core | +---+
/ \ \ +---+ +---+ +---+
| Dialog | | Conf | | Audit | | Core | | Core | | Core | +---+ +---+ +---+
________ \_______________________________________ | --- | / \ \ \ \ \ | +---+ +---+ +---+ +---+ +---+ +---+ | |Dialog| |Dialog | |Dialog| |Dialog| |Dialog| |Dialog | | |Base | |Transform| |Group | |Speech| |Fax | |Fax | | +---+ +---+ +---+ +---+ |Detect| |Send/ | | +---+ |Receive| | +---+ | ________________________|
/ \ \ \ +---+ +---+ +---+ +---+
|Audit| |Audit| |Audit | |Audit | |Conf | |Conn | |Dialog| |Stream|
+---+ +---+ +---+ +---+
o MSML Core Package (Mandatory)
Describes the minimum base framework that MUST be implemented to support additional core packages.
o MSML Conference Core Package (Conditionally Mandatory, for Conferencing)
Describes the audio and multimedia basic and advanced conferencing package that MAY be implemented.
o MSML Dialog Core Package (Conditionally Mandatory, for Dialogs) Describes the dialog core package that MUST be implemented for any dialog services. However, systems supporting conferencing only, MAY omit support for MSML dialogs. The MSML Dialog Core Package specifies the framework within which additional dialog packages are supported. The MSML Dialog Base Package MUST be supported, while all other dialog packages MAY be supported.
o MSML Dialog Base Package (Conditionally Mandatory, for Dialogs)
o MSML Dialog Group Package (Optional) o MSML Dialog Transform Package (Optional) o MSML Dialog Fax Detection Package (Optional) o MSML Dialog Fax Send/Receive Package (Optional) o MSML Dialog Speech Package (Optional)
o MSML Audit Core Package (Conditionally Mandatory, for Auditing) Describes the audit core package that MUST be implemented to support auditing services. The MSML audit core package specifies the framework within which additional audit packages are
supported.
o MSML Audit Conference Package (Conditionally Mandatory, for Auditing Conference, Conference Dialog, and Conference Stream) o MSML Audit Connection Package (Conditionally Mandatory, for Auditing Connection, Connection Dialog, and Connection Stream) o MSML Audit Dialog Package (Conditionally Mandatory, for Auditing Dialog, and MUST be used with either MSML Audit Conference
Package or MSML Audit Connection Package)
o MSML Audit Stream Package (Conditionally Mandatory, for Auditing Stream, and MUST be used with either MSML Audit Conference
Package or MSML Audit Connection Package)
The formal process for defining extensions to MSML dialogs is to define a new package. The new package MUST provide a text
description of what extensions are included and how they work. It MUST also define an XML schema file (if applicable) that defines the new package (which may be through extension, restriction of an
existing package, or a specific profile of an existing package).
Dependencies upon other packages MUST be stated. For example, a package that extends or restricts has a dependency on the original package specification. Finally, the new package MUST be assigned a unique name and version.
The types of things that can be defined in new packages are:
o new primitives
o extensions to existing primitives (events, shadow variables, attributes, content)
o new recognition grammars for existing primitives o new markup languages for speech generation
o languages for specifying a topology schema o new predefined topology schemas
o new variables / segment types (sets & languages) o new control flow elements
MSML packages are assembled together to form a specific MSML profile that is shared between different implementations. The base MSML dialog profiles that are defined in this document consist of the MSML Core Package, MSML Dialog Core Package, MSML Dialog Base Package, MSML Dialog Group Package, MSML Transform Package, MSML Fax Packages, and the MSML Speech Package.
MSML extension packages, which define primitives, MUST define the following for each primitive within the package:
o the function that the primitive performs
o the attributes that may be used to tailor its behavior o the events that it is capable of understanding
o the shadow variables that provide access to information determined as a result of the primitive’s operation
The mechanism used to ensure that a media server and its client share a compatible set of packages is not defined. Currently, it is
expected that provisioning will be used, possibly coupled with a future auditing capability. Additionally, when used in SIP networks, packages could be defined using feature tags and the procedures
defined for Indicating User Agent Capabilities in SIP [i1] used to allow a media server to describe its capabilities to other user agents.
4.2. Profile Scheme
Not all devices and applications using MSML will need to support the entire MSML schema. For example, a media processing device might support only audio announcements, only audio simple conferencing, or only multimedia IVR. It is highly desirable to have a system for describing what portion of MSML a particular media processing device
The package scheme described earlier allows MSML functionality to be functionally grouped, relying on the MSML core package. This scheme allows a portion of the complete MSML specification to be
implemented, on a per-package basis, and also creates a framework for future extension packages. However, within a given package, in some cases, only a subset of the package functionality may be required.
In order to support subsets of packages, with greater degree of granularity than at the package level, a profile scheme is required.
MSML package profiles would identify a subset of a given MSML package with specific definitions of elements and attributes. Each MSML package profile MUST be accompanied by one or more corresponding schemas. To use the examples above, there could be an audio announcements profile of the MSML Dialog Base Package, an audio simple conferencing profile of the MSML Conference Core Package, and a multimedia IVR profile of the MSML Dialog Base Package.
MSML package profiles MUST be published separately from the MSML specification, in one or more standards documents (e.g., Internet Drafts or RFCs) dedicated to MSML package profiles. Profiles would not be registered with IANA and any organization would additionally be free to create its own profile(s) if required.