Accredited Standards Committee

X3, INFORMATION PROCESSING SYSTEMS

 Table of Contents

1.0 FIXED EVENTS - none

• Prioritize
• Establish agenda item leader
• Define allotted time

• Approve prior minutes
• Establish meeting fee - OMG fee covers the meeting
• Review/establish future meeting plans

• Membership status report
• none
• Liaison reports
• None

2.5 Special topics

• Review and work on working document developed at Canberra ISO meeting on Enterprise Viewpoint work item.

• A major revision of the report will be submitted at the Final Report. It will also be submitted as an ANSI document (see motion).

• Haim Kilov submitted a paper on Business Rules X3H7-97-06

• Minutes from meeting 19 still need to be approved.

• OMG Business Object Facility, Meta-Object Facility, and OA&D Facility were discussed as some length.

• A major revision will be submitted and proposed as an ANSI document.

 MOTION: Ask Tom Kurihara to advise OMC that X3H7 wants to be the TAG for the Enterprise Viewpoint work. (Frank Manola moved, Haim Kilov second, passed by unanimous consent)

 Meet with OMG Object Model Subcommittee and OMG Business Object Domain Task Force. Described work and called for volunteers at the Object Model meeting.

 1:00 PM Meeting Convened

 Next meeting will be in Montreal concurrent with the OMG meeting in June. Following meeting will be at OOPSLA in October.

 Do we want to be the U.S. TAG on the Enterprise Viewpoint work. It requires additional administrative overhead and doubles the membership fee to $600. Joaquin is the project editor independent of TAG status.

 Do we want to merge with X3T3? If they have to be the TAG, they will want us to merge with them.

 MOTION: Ask Tom Kurihara to advise OMC that X3H7 wants to be the TAG. (Frank Manola moved, Haim Kilov second, passed by unanimous consent)

 MOTION: Submit the final draft of the X3H7 Technical Report for approval as an ANSI document. (Jeff Sutherland moved, Roger Burkhart second, 5 for, 0 against, no abstentions)

 Discussed formalizing relationship with OMG. No action at this time. Open for discussion at future meetings.

 ODP-RM Part I: Overview is available in hard copy from Joaquin. Parts II and III are available on the Web <www.iso.ch:8000/RM-ODP>

The Working document for RM-ODP Enterprise Viewpoint and Application Architecture developed at the last ISO/IEC JTC 1/SC 21 meeting was discussed.

Overlap with other ongoing efforts was examined. KIF is another possible technique to use for specification of an enterprise system.

In Section 11, Notation "(Information)" means for information only, not part of the standard. It should be taken out as it relates to another standard under consideration. If that becomes standard then there should be a reference to the standard.

GRM includes for historical reasons a lot of informative material that makes it difficult to read and use. We need to select the parts we want to refer to. (Haim).

What is our OMG alignment strategy?

• CDL metamodel in JBOF, should it become a standard
• MOF model - UNISYS meta-meta-model is one of several on fast track for BOF/OA&D/MOF. The OMG Architecture Board has declared that BOF, MOF, and OA&D will use the same metamodel.
• RM-ODP
• OA&D standards development
• Application of Features Matrix

Joaquin has been working with OA&D Task Force models and there is a core set of concepts that are meta to themselves. Do these support all the constructs in the X3H7 Object Model Features Matrix (Self for example)? (not sure)

The Object Model Features Matrix provides a mechanism for evaluating models. The RM-ODP is only partially in the Features Matrix. UML and MOF are not in it. Do we need to do any work there? (maybe)

If people are going to worry about Enterprise viewpoints as opposed to the OA&D Facility do we have to have clear insight into these meta issues? (Frank)

Two action items:

1. It is now the responsibility of X3H7 to do the mapping of RM-ODP to OMG Facilities (Haim). We need to do something with the boundary meeting issues.

2. What is the action plan between now and June on the Draft document for the next international meeting.

Item1:

MOF attempts to define a meta-meta-model that can define meta-models, that can describe classes that describe instances. If meta-model core is sufficient to describe the meta-model, you do not need a meta-meta-model to describe it. This is possible if we are in a well-defined domain (like OA&D methods), then the core is easily identified.

The meta-object-facility is the thing you need when you go across areas and things are a lot more different than you might think. For example, when we mix, in the Features Matrix, programming languages and Express there was a certain amount of disconnect. Programs have methods that implement behavior. Conceptual models do not necessarily have these notions. (Frank)

If we collapse the meta-meta-model into the core of the meta-model, when other dissimilar models come along, they may not map to the core. (Frank)

But the MOF, JBOF, and OA&D models are collapsible into a core. (Joaquin)

This implies that the proposed MOF may not be adequate for future model mapping. (Frank)

I've worked on defining the CDIF metamodel for the last five years and am Chair of the CDIF Committee. Jim Odell has presented an example of how the meta levels can continue upward indefinitely. CDIF collapses the transfer information from one system to another into the model level and assumes a set of meta-level concepts. (Woody)

Can we always take a set of core concepts that define a domain and use that core to be self describing and not need a metamodel? (Yes) When new domains appear, can we not expand the core to include it and still not need a meta-model. (No)

The things I use to build the model are my meta-model. (Woody) An example was drawn defining a process with boxes and lines. More than that is needed (Haim). You need pre- and post-conditions.

A thing and a description of the thing is a level of stratification. (Frank) The CDIF work has come up with a architecture based on three levels, because it is useful for extensibility. (Woody) You must distinguish between the thing described and the description. The description may or may no have the concepts necessary to describe itself. (Frank)

The answer to this discussion: The OMG Architecture Board has specified that the MOF, BOF, and OA&D will have the same meta-model. Therefore the meta-meta-model must be the same as the meta-model.

Relabel instance level as "things in a universe of discourse." I then build a model of it using a minimal set of constructs to define the things. I believe it is not only the things, but the associations and the relationships between the things. I need the meta-model because we need an agreement on the language we are using to describe the model. (Woody)

An instance can be a contract between an employer and an employee. At the model level we have an employment contract. Preconditions are at the model level. The concepts of precondition, relationships, etc. are at the meta-model level. (Haim)

Extensibility requires redescribing the model of the instance level when new instances appear that do not fit the old model. When a new concept appears that the current instance structure does not support (relations do not support objects), then the instance storage structure must change. (Bill)

The interesting challenge of defining meta-object protocols is defining enough constraints on the meta-object definitions so that you do not have infinite variability which causes systems to malfunction. (Frank)

Lassie is collie which is an instance of species which is an instance of ….

But collie is a class which is an instance of a metaclass - a different viewpoint. (Woody)

RM-ODP says what abstraction is. Eliminating unnecessary detail to define a simplified model. (Haim) Meta is not the same think as abstraction. Example is cars and trucks abstracted to position, velocity, and mass. There is nothing meta here. (Joaquin)

RM-ODP definition of model is Webster's definition of model.

Meta is a type of abstraction. It is not orthogonal to abstraction. It may be more than just a type of abstraction. (differing opinions)

There a programming languages where for each object there is a meta-object. The meta-object contains the description, the code that implements the object behavior. When you send a message to an object, the meta-object gets it. It is so that any instance can have its own behavior. The class describes the common features of a bunch of objects. (Frank)

We observe that this thing and that thing (pointing to two chairs) have something in common. They are each a chair (a model). We look at what is similar between chairs and dogs and we might abstract to a meta-model. (Haim)

Model can be viewed as a mapping between concepts and things in a universe of discourse. One mapping is a dog. Another is a cat. The dog or a cat is a relationship between a concept and the instances. A type is a relationship. The model itself is an expression of the mapping. The model doesn't mean anything unless you understand the meta-concepts and the universe of discourse. (Steve) This is an abstraction that happens only after you've done the three levels. (Frank)

To distinguish between a dog and a cat, I must describe the specific things that are different between the dog and the cat and this is the model. (Frank)

Frank maps to person maps to type. Dog maps to animal maps to type. Walking maps to activity maps to "???". "Frank walks the dog" maps to "???". (Haim)

In Japanese, the honorifics in the language are difficult for Americans to understand. This is because they are a description of the situation. A salutation would actually mean "I am a man at the door that a woman of higher rank just opened." Each situation has its own description, analogous to an object language where each object can have its own behavior. Information does not transfer between Japanese and English (at least without a lot of difficulty) because the metamodels are different. Here is an example where we need a meta-meta-model to be able to talk about both environments.

Everything in the UML must be captured by MOF at a minimum. This is probably on track for adoption already. A minority opinion feels that we should push for a MOF to be a minimal subset of concepts. This is probably not under serious consideration.

If MOF needs any new concepts, these concepts must be in the OA&D model. (Joaquin) What we really want is something that is extensible. (Frank)

Object modeling is more complex than arithmetic. Godel has show that you cannot have a system even in arithmetic that can prove every true thing within the system without the system proving some false concepts to be true. Peter Wegner has just shown that "interactive" systems are not Turing machines and cannot be fully specified.

Frank Manola met with OMG Meta-Object Facility Task Force.

Joaquin was given instructions at Canberra for further editing of a WG7 working document. We will use this as a starting point for developing a U.S. submission for the next Enterprise Viewpoint meeting in Helsinki.

• Application architecture should be mentioned in overview but not be a separate section.
• Categorized concepts are useful for working on the standard but should not be part of the main body of the standard.
• Diagrams should not be in the main part of the standard.
• The level of precision required is not available.
• To get the level of precision required would require a substantial amount of work.
• Diagrams imply support of a particularly notation.
• Interoperability between enterprises is problematic. We can specify schema, but the semantics of the data vary between countries and institutions. We can make some headway here but definition of all the semantics of information passed between enterprises is not possible. This needs to be done in other standards (HL7 for passing medical data as an example).
• Section 4.2 is a working note that should be identified as such and moved to the end of Section 4.
• Precise does not mean detailed.
• If you specify enterprise systems with use cases, the enterprise language will allow you to more precisely specify use cases, understand what needs to be specified more clearly, and know what does not belong in a specification. It will provide criteria for determining whether a specification is good or bad.
• 2.3.1.5: Role in RM-ODP is covered by definition of type and template type. "Role: identifier for a behavior, which may appear as a parameter in a template for a composite object, and which is associated with one of the component objects of the composite object." The OMG BOF role is covered by the RM-ODP definition of type, i.e. a behavior type. The enterprise language standard needs an improved (extended) definition for role.
• 6.5.1 Australia has identified several inadequacies in the current ODP enterprise language and proposes changes for use in the Enterprise language specification. This will require going through proper procedures for updating the RM-ODP standard.
• 6.5.1.1. The Objective of an ODP system is defined in RM-ODP. It is expressed as a contract which specifies how the objective can be met (RM-ODP 2-5.1.1). RM-ODP 2-5.2 - The objectives in scope of the ODP system are defined in terms of the roles it fulfils within the community of which it is part, and policy statements about those roles.
• 6.5.1.3 Incorporating mechanisms commonly used in economic transactions (resource, service, service provider, user) should be done in the context of Geerts and McCarthy who provide a rigorous statement of the appropriate object model for these concepts that should be standard in all business systems (X3H7-97-09).
• The Enterprise language standard should simply become a section of RM-ODP rather than a separate document (Paul).
• 7.1.1. French contribution points out that Enterprise specifications are the basis for creation of the Information specification since it must support the information in the Enterprise specification.

Meet with OMG Boundary Working Group, to discuss common issues concerning the Meta-Object Facility, Business Object Facility, and Analysis and Design Facility. Described work and called for volunteers.

Meet with Analysis and Design Domain Task Force. Described work and called for volunteers.