
//%/////////////////////////////////////////////////////////////////////////////
//
// Copyright (c) 2000 The Open Group, BMC Software, Tivoli Systems, IBM
//
// Permission is hereby granted, free of charge, to any person obtaining a
// copy of this software and associated documentation files (the "Software"),
// to deal in the Software without restriction, including without limitation
// the rights to use, copy, modify, merge, publish, distribute, sublicense,
// and/or sell copies of the Software, and to permit persons to whom the
// Software is furnished to do so, subject to the following conditions:
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
// DEALINGS IN THE SOFTWARE.
//
//==============================================================================
//
// Author: Karl Schopmeyer (k.schopmeyer@opengroup.org)
//
// Modified By: Karl Schopmeyer (k.schopmeyer@opengroup.org)
//
//%/////////////////////////////////////////////////////////////////////////////

/* This file contains the definition of terms used in the Pegasus implementation, the CIM defintions, and the Pegasus documentation.
WARNING: Because of some limits with DOC++ today, the tags \Ref and @link
do not work.  Therefore, references to these definitions can only be made with a direct URL as follows:

\URL[Namespace]{DefinitionofTerms.html#NAMESPACE}

Note that this implies the exact name of the file created from this document (DefinitionofTerms.html.  If you change the @name definition below that represents the lead section name, it will change the name of the file and everything else will fall apart.
Note also that we have a standard form for all definitions
<B>Namespace</B>\Label{NAMESPACE}
So that each one has a Name and generates an HTML in page label.

*/
/*
TODO LIST
Add classname definition  this is alreadyreferenced as CLASSNAME
*/

/** @name Glossary
This section provides definitions of terms and concepts used in the specification  of the  DMTF CIM and WBEM specifications
or in the definition and documentation of of the OpenPegasus implementation.

<P><P>

<B>Association</B> \Label{ASSOCIATION} -An association is a relationship between two classes or between instances of two classes. The properties of an association class include pointers, or references, to the two classes or instances.
Class association is one of the most powerful CIM features. It provides a way to organize a collection of management objects into meaningful relationships. For example, a CIM_ComputerSystem object might contain a CIM_Disk, Processor A, and Processor B. The CIM_ComputerSystem has an association with each of the objects it contains. Because this particular association is a containment association, it is represented by a class called CIM_contains. The CIM_contains class contains references to each of the objects that belong to the association. In this case, CIM_contains has a reference to Solaris_Disk and a reference to CIM_ComputerSystem.

<B>Association</B> \Label{Association} - A class that expresses the relationship between two other classes. The relationship is established by the presence of two or more references in the association class pointing to the related classes.

<B>CIM INSTANCE</B> \Label{CIMINSTANCE} - 

<B>CIMOM</B> \Label{CIMOM}  A CIMOM (CIM Object Manager) is the the terminology used to define the implementation of the CIM_Server defined in the CIM Operations over HTTP specification.  Typically a CIMOM includes the functions of the CIM Server, repositories, providers and the tools to start, run, etc. the CIM server.  CIMOM is an implement term and is not clearly defined in the DMTF documents as opposed to CIM Server which has a clear definition.

<B>DMTF</B> \Label{DMTF} - The Distributed Management Task Force (DMTF), a group representing corporations in the computer and telecommunications industries, is leading the effort to develop and disseminate standards for management of desktop environments, enterprise-wide systems, and the Internet. The goal of the DMTF is to develop an integrated approach to managing networks across platforms and protocols, resulting in cost-effective products that interoperate as flawlessly as possible. For information about DMTF initiatives and outcomes, see the DMTF web site at http://www.dmtf.org.

<B>Aggregation</B> \Label{Aggregation } -A strong form of an association. For example, the containment relationship between a system and the components that make up the system can be called an aggregation. An aggregation is expressed as a Qualifier on the association class. Aggregation often implies, but does not require, that the aggregated objects have mutual dependencies.


<B>Cardinality</B> \Label{Cardinality} -  A relationship between two classes that allows more than one object to be related to a single object. For example, Microsoft Office* is made up of the software elements Word, Excel, Access and PowerPoint.

<B>CIM</B> \Label{CIM} -  Common Information Model is the schema of the overall managed environment. It is divided into a Core model, Common model and extended schemas. CIM Schema The schema representing the Core and Common models. Versions of this schema will be released by the DMTF over time as the schema evolves.

<B>Class</B> \Label{CLASSDEFINITION} -  A collection of instances, all of which support a common type; that is, a set of properties and methods. The common properties and methods are defined as features of the class. For example, the class called Modem represents all the modems present in a system. Common model A collection of models specific to a particular area, derived from the Core model. Included are the system model, the application model, the network model and the device model.

<B>Core model</B> \Label{Core model} -  A subset of CIM, not specific to any platform. The Core model is set of classes and associations that establish a conceptual framework for the schema of the rest of the managed environment. Systems, applications, networks and related information are modeled as extensions to the Core model.

<B>Domain</B> \Label{Domain} -  A virtual room for object names that establishes the range in which the names of objects are unique.

<B>FLAVOR</B> \Label{FLAVOR - ATTN:

<B>Explicit Qualifier</B> \Label{Explicit Qualifier} -  A qualifier defined separately from the definition of a class, property or other schema element (see implicit qualifier). Explicit qualifier names must be unique across the entire schema. Implicit qualifier names must be unique within the defining schema element; that is, a given schema element may not have two qualifiers with the same name.

<B>Extended schema</B> \Label{Extended schema} -  A platform specific schema derived from the Common model. An example is the Win32 schema.

<B>Feature</B> \Label{Feature} -  A property or method belonging to a class.

<B>Flavor</B> \Label{Flavor} -  Part of a qualifier spcification indicating overriding and inheritance rules. For example, the qualifier KEY has Flavor(DisableOverride ToSubclass), meaning that every subclass must inherit it and cannot override it.

<B>Implicit Qualifier</B> \Label{Implicit Qualifier} -  A qualifier defined as a part of the definition of a class, property or other schema element (see explicit qualifier).

<B>Indication</B> \Label{Indication} - A type of class usually created as a result of the occurrence of a trigger.

<B>Inheritance</B> \Label{Inheritance} -  A relationship between two classes in which all the members of the subclass are required to be members of the superclass. Any member of the subclass must also support any method or property supported by the superclass. For example, Modem is a subclass of Device.

<B>Instance</B> \Label{Instance} -  A unit of data. An instance is a set of property values defined by a CIM Class that can be uniquely identified by a key.

<B>Key</B> \Label{Key} -  One or more qualified class properties that can be used to construct a name for an instance. 
The key uniquely identify instances of this instance in a namespace.  Key properties are defined by the existence of the key qualifier attached to the
property. All instances MUST have keys except for those types of instances specifically identified as exceptions in the CIM Specification. This includes
indications which DO NOT have keys because they are transitory and the singleton class which provides for the concept of a class with only one
instance. NOTE: TOday there is an issue with the concept of the singleton class since it is defined only in the cimxm. documentation.



<B>MOF</B> \Label{MOF} - MOF is the standard language used to define elements of the Common Information Model (CIM). The MOF language specifies syntax for defining CIM classes and instances. Compilation of MOF files provides developers and administrators with a simple and fast technique for modifying the CIM Repository. For more information about MOF, see the DMTF web page at http://www.dmtf.org.


<B>PROPERTY</B> \Label{PROPERTY} - ATTN:

<B>Repository</B> \Label{} - The CIM Repository stores the CIM metaschema (class repository) and instance information (instance repository). TheRepository is provided as part of the reference implementation,  but is considered an independent service for the CIMOM. The interfaces to the respository are fixed but the supplied respository can be replaced with a different implementation.

<B>WBEM</B> \Label{WBEM} - ATTN:


<B>MOF</B> \Label{MOF} - MOF is the standard language used to define elements of the Common Information Model (CIM). The MOF language specifies syntax for defining CIM classes and instances. Compilation of MOF files provides developers and administrators with a simple and fast technique for modifying the CIM Repository. For more information about MOF, see the DMTF web page at http://www.dmtf.org.

<B>XmlCIM</B> \Label{XMLCIM} - The XML Schema describes the CIM metaschema. The CIM classes and instances are valid XML documents.

A Metaschema Mapping is one where the XML schema is used to describe the CIM metaschema, and both CIM classes and instances are valid XML documents for that schema. In this case, the DTD is used to describe, in a generic fashion, the notion of a CIM class or instance. CIM element names are mapped to XML attribute or element values. An alternate mechanism maps XML documents directly to CIM schema classes and instances. In this case, CIM element names are mapped to XML element names The advantages of the XML descriptions are: Only one DTD needs to be defined Avoids the limitations of DTD's (ordering, scoping, and no inheritance) Straightforward

For more detailed information on the mapping of XML to CIM schema, see
http://www.dmtf.org/download/spec/xmls/CIM_XML_Mapping20.htm and
http://www.dmtf.org/download/spec/xmls/CIM_HTTP_Mapping10.htm.
1.5 Managed Object Format

<B>Managed Object</B> \Label{Managed Object} - The actual item in the system environment that is accessed by the provider. For example, a Network Interface Card.

<B>Meta model</B> \Label{Meta model} -  A set of classes, associations and properties that expresses the types of things that can be defined in a Schema. For example, the meta model includes a class called property which defines the properties known to the system, a class called method which defines the methods known to the system, and a class called class which defines the classes known to the system.

<B>Meta schema</B> \Label{Meta schema} -  The schema of the meta model. Method A declaration of a signature; that is, the method name, return type and parameters, and, in the case of a concrete class, may imply an implementation.

<B>METHOD</B> \Label{METHOD} - Methods represent the behavior relevant for a class. A method is defined as an operation together with its signature.
The signature consists of a possibly empty list of parameters and a return type. 
A declaration of a signature; that is, the method name, return type and parameters, and, in the case of a concrete class, may imply an implementation.
Including a method in a class does not guarantee an implementation of the method.
The Implemented qualifier is attached to the method to indicate that an implementation is available for the class.

<B>Model</B> \Label{MODEL} - A set of classes, properties and associations that allows the expression of information about a specific domain. For example, a Network may consist of Network Devices and Logical Networks. The Network Devices may have attachment associations to each other, and may have member associations to Logical Networks.

<B>Model Path</B> \Label{Model Path} -  A reference to an object within a namespace. 
Namespace An object that defines a scope within which object keys must be unique.

A reference to an object within a namespace. Namespace An object that defines a scope within which object keys must be unique.


<B>Namespace</B>\Label{NAMESPACE} An object that defines a scope within which object keys must be unique. Multiple namespaces typically indicate the presence
of multiple management spaces or multiple devices.

The namespace pragma
    <PRE>
    	#pragma namespace( )
    </PRE>
This pragma is used to specify a Namespace path. The syntax
needs to conform to the following:
    <PRE>
    	&lt;namespacetype&gt://&lt;namespacehandle&gt
    </PRE>


<P>The contents of a MOF file are loaded into a Namespace that provides a domain (in other words, a container), in which the instances of the classes are guaranteed to be unique per the KEY qualifier definitions. The term namespace is used to refer to an implementation that provides such a domain.
Namespaces can be used to:
<UL>
    <LI>Define chunks of management information (objects and associations) to limit implementation resource requirements, such as database size.
    <LI>Define views on the model for applications managing only specific objects, such as hubs.
    <LI>Pre-structure groups of objects for optimized query speed.
 </UL>
 
<B>QUALIFIER</B> \Label{qualifier} - Qualifiers
    are values that provide additional information about classes, associations,
    indications, methods, method parameters, triggers, instances, properties or
    references. All qualifiers have a name, type, value, scope, flavor and default value. Qualifiers cannot be duplicated; there cannot be more than one qualifier of the same name for any given class, instance, or property.
    
    Qualifiers are defined in detail in the DMTF CIM Specification.
    
    There are several types of Qualifiers as listed below:
    <UL>
    <LI><B>Meta-Qualifiers</B> - (ASSOCIATION,INDICATION are the MetaQualifiers) are used to refine the definition of the meta constructs in the model. These qualifiers are used to refine the actual usage of an object class or property declaration within the MOF syntax.
    
    <LI><B>StandardQualifiers</B> -(See CIM Specificaiton for a list) All CIM-compliant implementations are required to handle. Any given object will not have all of the qualifiers listed.
    
    <LI><B>Optional Qualifiers</B> - The optional qualifiers listed in the CIM Specificaiton address situations that are not common to all CIM-compliant
implementations. Thus, CIM-compliant implementations can ignore optional
qualifiers since they are not required to interpret or understand these qualifiers.

PEGASUS Implements the following optional Qualifiers - ATTN:
    
    <LI>User Defined Qualifiers</B> - The user can define any additional arbitrary named qualifiers. However, the CIM specificaiton recommends that
only defined qualifiers be used, and that the list of qualifiers be extended only if there is no other way to accomplish a particular objective.
    
    </UL>
    ATTN: Should we include the table of qualifiers?????


<B>Namespath Path</B> \Label{Namespath Path} -  A reference to a namespace within an implementation that is capable of hosting CIM objects.

<B>Name</B> \Label{Name} -  Combination of a Namespace path and a Model path that identifies a unique object.

<B>Trigger</B> \Label{Trigger} -  The occurrence of some action such as the creation, modification or deletion of an object, access to an object, or modification or access to a property. Triggers may also be fired as a result of the passage of a specified period of time. A trigger typically results in an Indication.

<BPolymorphism></B> \Label{Polymorphism} -  A subclass may redefine the implementation of a method or property inherited from its superclass. The property or method is thereby redefined, even if the superclass is used to access the object. For example, Device may define availability as a string, and may return the values “powersave”, "on" or "off." The Modem subclass of Device may redefine (override) availability by returning "on," "off," but not "powersave". If all Devices are enumerated, any Device that happens to be a modem will not return the value "powersave" for the availability property.

<B>Property</B> \Label{Property} -  A value used to characterize an instance of a class. For example, a Device may have aproperty called status.

<B>Provider</B> \Label{Provider} -  An executable that can return or set information about a given managed object. Qualifier A value used to characterize a method, property, or class in the meta schema. For example, if a property has the qualifier KEY with the value TRUE, the property is a key for the class.

<B>Reference</B> \Label{Reference} -  Special property types that are references or "pointers" to other instances.

<B>Schema</B> \Label{Schema} -  A namespace and unit of ownership for a set of classes. Schemas may come in forms such as a text file, information in a repository, or diagrams in a CASE tool.

<B>Scope</B> \Label{}Scope -  Part of a Qualifier specification indicating with which meta constructs the Qualifier can be used. For example, the Qualifier ABSTRACT has Scope(Class Association Indication), meaning that it can only be used with Classes, Associations and Indications.

<B>Scoping Object</B> \Label{ScopingObject} -  Objects which represent a real-world managed element, which in turn propagate keys to other objects.

<B>Signature</B> \Label{Signature} -  The return type and parameters supported by a method.

<B>Subclass</B> \Label{Subclass} -  See Inheritance.

<B>Superclass</B> \Label{Superclass} -  See Inheritance.

<B>Top Level Object</B> \Label{TopLevelObject} -  A class or object that has no scoping object.




