Version 1.00

November 17, 2005

Members and Contributors:

IBM Corporation, Fujitsu Limited

© Copyright IBM Corporation 2005 All rights reserved. May only be used pursuant to an IBM Software License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM Corporation. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose.
U.S. Government Users Restricted Rights—Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation.

Table of Contents

1Purpose

2Extended WEF

3Proposed WEF 1.0 addition

3.1Proposal: Message Catalog Extensions

3.1.1ManagementEvent message catalog

3.1.1.1msgCatalog

3.1.1.2msgCatalogType

3.1.1.3msgCatalogInformation Schema

3.2Changes required to existing WSDM specification

1Purpose

This document proposes an extensions to the OASIS Web Services Distributed Management (WSDM) Event Format (WEF) version 1.

The proposal in this document is based on a specification, Extended WSDM Event Format (exWEF) Specification, jointly developed between IBM Corporation and Fujitsu Limited. This specification defines the schema that IBM, Fujitsu, and their partners will use in mapping between IBM’s Common Base Event (CBE) and WEF so that Extended WEF can provide the same semantic richnessoffered by the IBM Common Base Event version 1.0.1. The specification uses the standard extension points that are part of the OASIS WEF definition but normatively defines additional elements and best practices necessary to ensure lossless conversion between the two formats.

IBM, Fujitsu, and their partners intend to publish the Extended WSDM Event Format Specification to improve interoperability in the industry. Only portions of the exWEF specification are being proposed to the OASIS WSDM Technical committee (TC) since a number of elements in CBE relate to information models that the WSDM TC has chosen to remain agnostic.

2Extended WEF

The exWEF specification defines standard extensions to WEF as shown in the UML diagram of Figure 1.

Figure 1Extended WEF UML

In Figure 1, the blue (dark shaded) elements are those defined in the WEF specification. The <any> elements are the extension points defined in the WEF specification. The white (not shaded) and gray (light shaded) elements are the extensions defined in exWEF specification (gray denotes new elements; white denotes elements reused from the Common Base Event). Although the diagram indicates that several new properties are added for the WEF extensions, not all of these properties are required for all events, and not all of them are required to be generated by event producers (rather, in some cases, the specified extended information is added to the event as it traverses a path in the system).

The Extended WEF extensions make use of the standardized <any> element extension points defined in the WSDM 1.0 specification and generally take one of these forms:

  • Additional elements and attributes taken from the Common Base Event and added to existing WEF elements to increase the semantic richness and usefulness
  • Recommended canonical situation qualifier values taken from the Common Base Event and used to refine the Situation classification for an event.
  • Extended contentto accommodate additional situations (business events, security events and so on) and supplemental information that is relevant for certain situations, in a flexible manner.

3Proposed WEF 1.0 addition

This proposal contains a single addition to WEF 1.0.

  • Add new element to muws-p1-xs:ManagementEvent to permit expression of message catalogs for internationalization.

3.1Proposal: Message Catalog Extensions

Add an additional element to muws-p1-xs:ManagementEventto permit definition of the form used to process the message catalog. Currently, WEF 1.0, does not providefor expressing a message catalog. The WEF 1.0 content is a simple text substitution string but this does not permit higher levels of internalization processing as defined in some industry standards like XPG4. Adding an OPTIONAL element will permit the expression of this additional information.

This proposal adds the following text to the ManagementEvent section of the WSDM MUWS Part 2 specification:

3.1.1ManagementEvent message catalog

The msgCatalogInformation element provides a means to define message catalog information that is to be used for internationalization of messages contained within the event. The msgCatalogInformation properties are detailed in Table 2 and the descriptions that follow. These properties enable the optional use of a message catalog for specifying messages.

This is an OPTIONAL property.

The elements within a msgCatalogInformation element are:

Element / Type / Description
msgCatalog / xsd:anyURI / The qualified name of the message catalog that contains the translated messages. Messages specified by the muws-p2-xs:Situation/SubstitutableMsg@MsgId attribute will be retrieved from this catalog. The format of the messages in the catalog is specified by the msgCatalogTypeelement.
This is an REQUIRED element.
msgCatalogType / xsd:anyURI / The msgCatalogTypeelement specifies the format of the messages in the msgCatalog. Values include but are not limited to:
  • Java
  • XPG
This element is REQUIRED.

Table 2ManagementEvent extensions for message catalog summary

3.1.1.1msgCatalog

The msgCatalogelement is the qualified URI of the message catalog that contains the locale-dependent message template that is indexed by the muws-p2-xs:Situation/SubstitutableMsg@MsgId attribute. The format of the messages in msgCatalog is specified by the msgCatalogTypeelement.

This element is REQUIRED.

3.1.1.2msgCatalogType

The msgCatalogType property specifies the format of the msgCatalog. The format defines the substitution identifier syntax for the muws-p2-xs:Situation/SubstitutableMsg/Value (that is, the method used to insert runtime information contained in the muws-p2-xs:Situation/SubstitutableMsg/Valueelement into the message template that is retrieved from the message catalog to form a completely translated message). The reserved keywords for msgCatalogType are:

  • JavaThe message catalog uses Java properties encoding. See
  • XPGThe message catalog uses X/Open XPG specifications for providing internationalization support. See

Other values may be used for other catalog types.

This element is REQUIRED.

3.1.1.3msgCatalogInformation Schema

The schema for msgCatalogInformation is:

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema

xmlns:xsd="

<xsd:element name="MsgCatalogInformation" type="MsgCatalogInformationType" minOccurs=“0” maxOccurs=“1”/>

<xsd:complexType name="MsgCatalogInformationType">

<xsd:sequence>

<xsd:element name="msgCatalog" type=“xsd:anyURI” />

<xsd:element name="msgCatalogType" type=“xsd:anyURI” />

</xsd:sequence>

</xsd:complexType>

<xsd:schema>

3.2Changes required to existing WSDM specification

The section related to muws-p2-xs:Situation/SubstitutableMsg, section 2.5.1, must be changed to address additional usage of the attribute @MsgId.

The WSDM specification text should be modified as follows:

muws2:Situation/muws2:SubstitutableMsg/@muws2:MsgId specifies the message identifier of an event. This identifier SHOULD be a unique value string, consisting of alphanumeric or numeric characters. The value can be as simple as a string of numeric characters that identify a message in a message catalog. As an alternative, the value can be a multipart string of alphanumeric characters, for example, DBT1234E. This is a REQUIRED attribute. The maximum string length for MsgId MUST NOT exceed 256 characters. The MsgIdType attribute indicates the formatting type of the MsgId.

MsgID is used as an index into muws-p2-xs:MsgCatalogInformation/MsgCatalog if MsgCatalogInformation is present.